Usage as dependency in apps that also use babel

[aweber1]

Ran into an odd issue today while using cross-var on Mac with an app that uses babel and webpack. Basically, when using a cross-var command in an npm script, we were getting an error originating from babel-preset-env. Which was odd because the npm script that we were running doesn't have anything to do with babel. After trying many things, we disabled the use of cross-var in that script and it then worked fine.

Looking at the source for cross-var, it appears that the main index.js file uses babel-require in order to do transpiling inline. My theory is that because cross-var depends on babel-register for inline transpiling, it was picking up our babel config and the presets being used by cross-var weren't matching what we used in the app.

Long story short, the fix is to transpile before publishing so that cross-var plays nicer with other babel consumers. Submitting a PR for this shortly. Nice side effect is removing dependency on babel from the installed package.

[iignatov]

@elijahmanor Could you please accept this PR? IMO there's no real need to require installation of all Babel dependencies (90+ packages) for such a simple package. Thanks in advance!

[lostpebble]

Yep, just ran into this issue today. cross-var was interfering with my babel pipeline because it started to pick up on earlier versions of babel-core etc. which were now installed as dependencies of cross-var.

To fix I had to explicitly install babel-core and babel-runtime at the versions I want - previously they were bundled with babel-cli I think.

[lostpebble]

I desperately needed this to get my project working with the newer versions of Babel - namely the new @babel scoped packages.

So I forked a pull request that removes babel completely and released a temporary substitute on npm, which you can use for now if you really need this as well:

"cross-var-no-babel": "^1.2.0"

Should continue to work exactly the same, just no more babel dependency.

[awto]

I solved the problem by replacing cross-var with cross-env as is, without any variable set, it substitutes var names too

[lostpebble]

@awto ... wish I had known that sooner. Thanks, will probably just be using that alone then (I was using both for some reason).

[eKoopmans]

@awto I found that cross-env didn't work, it just converted $npm_package_version to the text %npm_package_version%, which was passed as-is without being evaluated anywhere along the way. I tried cross-env-shell (as suggested here), which got a bit further, but ended up causing other complicated problems.

Anyway, the fork from @lostpebble is a nice temporary solution!

[lostpebble]

@eKoopmans I had the same issue with cross-env. For some reason you need to use a different command that's part of the cross-env package: cross-env-shell, so:

   "start": "cross-env-shell NODE_ENV=production node --max-old-space-size=$NODE_JS_MAX_OLD_SPACE_SIZE --max-semi-space-size=$NODE_JS_MAX_SEMI_SPACE_SIZE ./server.js",

That worked for me.

EDIT: Oh, nevermind - just saw you actually tried that... 😅

[eKoopmans]

Hah yep, I ran into a problem further downstream - a bit hard to replicate, but basically it was parsing text$var inconsistently (one part of the command composed them properly, but then git got confused and parsed them as two separate pieces). This package didn't have that problem.

That said, neither of them are going to work for me, because the variables don't update when I need them to - i.e. in a pre script I bump the version (with npm version), then in the main script I reference $npm_package_version, but the version is still the old one. It's not a problem in vanilla NPM.