WAIT HOLD ON
Everything I said above still stands, but there’s a much easier way to get Polymer packages to be recompiled, as long as you don’t need to modify them locally. But first, let me explain how the technique above actually works.
Because node_modules/@polymer/lit-element is a symbolic link to imports/lit-element, any pair of paths like
node_modules/@polymer/lit-element/lit-element.js
imports/lit-element/lit-element.js
have the same “real path” (that is, the normalized path you get after you remove any symbolic links).
Meteor 1.7 notices this relationship, and makes sure behind the scenes that both paths can be used to refer to the same module. In other words, it doesn’t matter whether you import @polymer/lit-element (preferred) or ./imports/lit-element (also ok), since there’s only one logical package, with two (or more!) different ways of referring to it.
The really cool thing about this behavior is that the relationship of “having the same real path” is technically an equivalence relation, which is a fancy way of saying it doesn’t make a difference which way the symbolic link points. In fact, both paths can contain symbolic links, so that neither of them is the real path, as long as they both share a common real path.
In other words, instead of cloning the source package locally and linking it into node_modules, you can just install the package from npm, and then create a symbolic link to the installed package somewhere outside of node_modules:
meteor npm install @polymer/lit-element
mkdir -p imports/links
cd imports/links
ln -s ../../node_modules/@polymer . # handles everything under @polymer/...
ln -s ../../node_modules/lit-html .
# ... keep going until you've "exposed" everything that needs to be recompiled
cd ../..
meteor run
And that’s it!
When you create the symbolic link in this direction, you’re selectively enabling recompilation for certain subdirectories of node_modules, without having to worry about building the packages from source.
As before,
node_modules/@polymer/lit-element/lit-element.js
imports/links/@polymer/lit-element/lit-element.js
both have the same real path, even though we’re now linking into node_modules instead of linking out of node_modules. Note: this variation of the technique can be a little tricky for Windows developers, since creating symbolic links is hard without admin privileges, but it’s totally doable. I’m happy to provide additional advice if this is relevant to you.
Best of all, Meteor will recompile the code in question in different ways for modern browsers, legacy browsers, and Node, which is something that just isn’t possible when you’re publishing a package to npm the normal way. In a sense, it’s a good thing that Polymer isn’t trying to make compilation decisions for you, since that would rob you of this amazing opportunity to optimize your JS bundles for different JS environments. More on this modern/legacy bundling system in the Meteor 1.7 blog post: