Esm: Application w/esm using dependency w/esm must be on same version
Hi @jdalton
We've started using esm throughout many applications and internal packages at my organization, and a recurring pain point is the need to have the application and all dependencies use the same version of esm. If the version of esm differs between app/dependency, very often the result is a syntax error:
import './newrelic';
^^^^^^
SyntaxError: [email protected] is not enabled for <path>
To cite the most recent example, the above occurred when a dependency was on esm@^3.0.19, and the application was on esm@^3.0.16; not a huge gap, with the versions being separated only by a few weeks.
This issue has been impacting us every few versions of esm, to the point where we're questioning whether using the library within dependencies is worthwhile; while upgrading esm within an application is a trivial exercise, needing to also upgrade all esm based dependencies is considerably more overhead.
Can you provide some insight into whether this is a fundamental issue that can be expected reoccur with most new versions, or should we expect this sort of pain to subside as the library matures?
CacheControl
All 14 comments
Hi @CacheControl!
At the moment the esm loader uses the dependency version as an opt-in gate. So by saying you depend on esm@^3.0.19 you exclude the lower esm@^3.0.16 range since 3.0.16+ is less than 3.0.19+. What I can do though is look for the ^ and assume any 3.x is allowed.
In other words it's not a fundamental issue just a the version gating mechanism we're using at the moment. It can totally, and should, be tweaked to support your usage.
Update:
Yep, that's what it is:
SemVer.maxSatisfying(["3.0.16"], "^3.0.19")
// => null
SemVer.maxSatisfying(["3.0.20"], "^3.0.19")
// => '3.0.20'
jdalton
on 18 Apr 2018
aha, great! Yes that would definitely solve our pain!
CacheControl
on 18 Apr 2018
I think I can use this instead:
SemVer.intersects("^3.0.16", "^3.0.19")
// => true
Until this is addressed you can work around this by simply planting your versions at ^3.0.0.
The ^ will ensure the latest v3 is used and opt-in the loader for all v3 ranges.
jdalton
on 18 Apr 2018
@CacheControl can you run a test build of this to see if it works for you?
jdalton
on 18 Apr 2018
@jdalton thanks! yep, I'll give it a go
CacheControl
on 18 Apr 2018
So this is just my thought, aren’t we only supposed to use esm as a dev dependency? Only the application use esm to load all the files, the lib will only provide ES module files.
Yun
On Apr 18, 2018, at 7:51 AM, Cache Hamm notifications@github.com wrote:
@jdalton thanks! yep, I'll give it a go
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Tundon
on 18 Apr 2018
aren’t we only supposed to use esm as a dev dependency
Nope. esm is intended for production use _(a direct dependency)_.
That's the _"production ready"_ bit of the tag line.
A fast, production ready, zero-dependency ES module loader for Node 6+!
It's also how npx create-esm and yarn create esm initialize packages.
jdalton
on 18 Apr 2018
@jdalton Can you provide some guidance on how to test this?
Edit: Nevermind, rm -rf node_modules and fresh install cleared this out for me.
CacheControl
on 18 Apr 2018
No worries. I've prebuilt it as esm-3.0.20.zip.
Update:
Ah, missed a critical bit to the patch.
Here is a new build: esm-3.0.20.zip.
Update:
Sorry, tests are failing... one second.
The issue was .intersects("*", smth).
Patch https://github.com/standard-things/esm/commit/5b5bd1cdccf7bcda9a7205caa62e58b76667834c; Related semver bug: https://github.com/npm/node-semver/issues/236
jdalton
on 18 Apr 2018
Shall I use the latest build you linked to test, or hold off for a new one?
CacheControl
on 18 Apr 2018
The third time's the charm: esm-3.0.20.zip
jdalton
on 18 Apr 2018
@jdalton I've done some testing and discussion, and I think I need to apologize for filing a non-issue.
We had several packages which were not playing nice with applications on various versions of esm (3.0.6, 3.0.8, 3.0.16, 3.0.19, among others) - a variety of different syntax errors were being thrown depending on the esm version combination and dependencies. These errors were encountered by multiple different team members, and so there was a general lack of trust that had developed recently around mixing esm versions.
The specific issue I filed above was due to troubleshooting to fix a syntax error in an [email protected] application with dependencies on several different esm versions. Trying different versions of the application's esm version in an attempt to identify one that worked for all dependencies, I was using the --no-save option of npm install. That eventually resulted in the package.json having a higher version number of esm than was actually installed, resulting in the error message posted above. My guess is the SemVer library esm uses references the content of package.json.
The syntax errors we encountered were fixed by your new build, but I'm fairly certain that's due to the upgrade itself, as installing 3.0.19 works as well.
Again, apologies!
CacheControl
on 18 Apr 2018
@CacheControl
No worries 😋
I think the patch is still a good thing as others (#366) were caught by a similar issue.
Thinking on this more the patch doesn't make sense. However, I will look into providing better guidance in the error message, e.g. _"If problems persist try deleting node_modules"_.
jdalton
on 18 Apr 2018
v3.0.20 is released :tada:
jdalton
on 19 Apr 2018
Related issues
dnalborczyk
·
3Comments
clock157
·
3Comments
tunnckoCore
·
3Comments
pvdlg
·
3Comments
deepsweet
·
3Comments
Most helpful comment
Nope.
esmis intended for production use _(a direct dependency)_.That's the _"production ready"_ bit of the tag line.
It's also how
npx create-esmandyarn create esminitialize packages.