Invalid Version: undefined

LeoMsky commented 3 years ago

Everything is OK yesterday，but I've had this problem since I installed it again this morning

skjb commented 3 years ago

FYI reverting to 1.12.3 seems to work

DarinTayTwoXAR commented 3 years ago

Pinning @babel/preset-env to 7.13.8 is what worked for me.

The version check that is failing here was added in 7.13.9 here - https://github.com/babel/babel/commit/c155caf1e8f229e546b22980ecb53313b90334d0#diff-cddb13dc00454073d19373b40529b8047e25b9141ab627eb8be482601f16eabe

vaibhavkumar-sf commented 3 years ago

Yes, reverting to 1.12.3 is working

bemnlam commented 3 years ago

Even a minimal repo with Parcel 1.12.4 installed does not work:

npm init -y && npm i parcel && touch index.js && echo "<html><body>Minimal Parcel<script src=\"./index.js\"></script></body></html>" > index.html

Add a dev command in package.json:

"scripts": {
  "dev": "parcel index.html"
},

And then run npm run dev. This is the error:

Server running at http://localhost:1234 
🚨  /Users/ben.lam/poc/testbuild/index.js: Invalid Version: undefined
    at new SemVer (/Users/ben.lam/poc/testbuild/node_modules/@babel/preset-env/node_modules/semver/semver.js:314:11)
    at compare (/Users/ben.lam/poc/testbuild/node_modules/@babel/preset-env/node_modules/semver/semver.js:647:10)
    at lt (/Users/ben.lam/poc/testbuild/node_modules/@babel/preset-env/node_modules/semver/semver.js:688:10)
    at /Users/ben.lam/poc/testbuild/node_modules/@babel/preset-env/lib/index.js:276:22
    at Object.default (/Users/ben.lam/poc/testbuild/node_modules/@babel/helper-plugin-utils/lib/index.js:22:12)
    at getEnvPlugins (/Users/ben.lam/poc/testbuild/node_modules/parcel/src/transforms/babel/env.js:62:34)
    at getEnvConfig (/Users/ben.lam/poc/testbuild/node_modules/parcel/src/transforms/babel/env.js:12:25)
    at async getBabelConfig (/Users/ben.lam/poc/testbuild/node_modules/parcel/src/transforms/babel/config.js:32:19)
    at async babelTransform (/Users/ben.lam/poc/testbuild/node_modules/parcel/src/transforms/babel/transform.js:6:16)
    at async JSAsset.pretransform (/Users/ben.lam/poc/testbuild/node_modules/parcel/src/assets/JSAsset.js:83:5)

Like the others, pinning Parcel to 1.12.3 in package.json can (temporarily) solve this problem. e.g.:

"dependencies": {
  "parcel": "1.12.3"
},

jansiegel commented 3 years ago

This seems to be caused by an update to babel@7.13.9 and this change in particular: https://github.com/babel/babel/pull/12934/files#diff-cddb13dc00454073d19373b40529b8047e25b9141ab627eb8be482601f16eabeR301

It requires an object with a version field to be passed to presetEnv, while parcel-bundler@1.12.4 doesn't to that: https://github.com/parcel-bundler/parcel/blob/parcel-bundler%401.12.4/packages/core/parcel-bundler/src/transforms/babel/env.js#L62

wachunei commented 3 years ago

It seems this bug is present on both v1 and v2 https://github.com/babel/babel/issues/12945#issuecomment-788858288

Although v1 is not maintained anymore, is it posssible to make an exception here and bump a patch in both version when the fix is available?

dwanl commented 3 years ago

Yes, I also had this problem

nicolo-ribaudo commented 3 years ago

You can workaround this by adding

"resolutions": {
  "@babel/preset-env": "7.13.8"
}

to your package.json file. With Yarn it will automatically download the previous @babel/preset-env version (which doesn't rely on the Babel API Parcel isn't providing); with npm you'll need https://www.npmjs.com/package/npm-force-resolutions to make it work.

mmikhalko commented 3 years ago

Please fix this bug ASAP

angeliquejw commented 3 years ago

The workaround posted by @nicolo-ribaudo worked for me; thanks, Nicolò!

devongovett commented 3 years ago

I don't believe this occurs in Parcel 2 FWIW. The codepath linked in the babel issue is never hit: config.isSource is always true due to https://github.com/parcel-bundler/parcel/blob/806cc65e0e430b1120cdcf1676e2f58738326d30/packages/transformers/babel/src/config.js#L39-L41

devongovett commented 3 years ago

I would encourage folks to try out v2 as it's much more stable and actively maintained whereas v1 has been unmaintained for some time. Personally, I don't use v1 in any of my projects anymore, and v2 is being used in production by some big companies like Adobe and Atlassian. While we are very close to a v2 release candidate, the best way for now is to pin to a recent nightly. If that doesn't work for you, you can try the workaround posted by @nicolo-ribaudo above.

tad-lispy commented 3 years ago

Prompted by this issue I just made a switch to v2 few hours ago and so far I'm very happy with it. I had a bit of trouble with compiling Elm, but eventually got it to work. See here for details: https://github.com/parcel-bundler/parcel/discussions/5948

saostad commented 3 years ago

I have this problem in v2 too.

tiennv-fireapps commented 3 years ago

I just install parcel global yesterday and applied these ways above, but still get this error.

leonsux commented 3 years ago

same problem

tienluckyfor commented 3 years ago

yarn global add parcel-bundler@1.12.3 then run parcel index.html work for me!

kappe commented 3 years ago

Server running at http://localhost:9999

🚨 /home/user/tmp/mist/src/index.js: Invalid Version: undefined at new SemVer (/home/user/tmp/mist/node_modules/semver/semver.js:314:11) at compare (/home/user/tmp/mist/node_modules/semver/semver.js:647:10) at lt (/home/user/tmp/mist/node_modules/semver/semver.js:688:10) at /home/user/tmp/mist/node_modules/@babel/preset-env/lib/index.js:276:22

we removed the semver statement inside the if clause "resolutions" is not working

Qix- commented 3 years ago

@devongovett @mischnic Might I suggest pinning this until it's resolved; I imagine you're going to see a lot more duplicates.

I would encourage folks to try out v2

Works great aside from the fact none of the plugins work for it. I do appreciate the much more stable file watching. But it's a non-starter since nothing aside from the core bundler works. It doesn't even detect old packages with an error or anything, it just silently ignores them.

EDIT: Downgrading to 1.12.3 doesn't work for me. Nuking node_modules didn't change anything. I also have package-lock.json disabled and have exact versions enabled. parcel --version reports 1.12.3. I'm still getting the same message.

<rant>

This isn't targeted at the Parcel devs in particular, though I'm getting really tired of having to have the "semver ranges are evil" talk and getting told I don't know what I'm talking about. 10 years later and these utopian views of perfect versioning semantics haven't panned out.

</rant>

To summarize https://github.com/parcel-bundler/parcel/issues/5943#issuecomment-788928442 for NPM users:

Make sure package-lock.json is enabled. If you have it disabled via e.g. .npmrc, remove that config line and add an entry into .gitignore if you must. It's required for this fix to work.
Add "preinstall": "npx npm-force-resolutions" to your scripts in package.json

Add the resolutions block to the root of package.json, e.g.:

{
"name": "my-package",
"scripts": {
"preinstall": "npx npm-force-resolutions"
},
"resolutions": {
"@babel/preset-env": "7.13.8"
}
}

If you have NOT already installed your node_modules, run npm i twice. This is because the first install only modifies the package-lock.json entry, but doesn't tell npm to actually install it. The second run will make npm see the pinned dependency edits and pull the correct version.

Note that this workaround only works at the top level; you cannot employ this as a library as it won't work for downstream consumers of your library. There's no workaround in such cases.

devongovett commented 3 years ago

@Qix- Which plugins in particular are you interested in?

Qix- commented 3 years ago

@devongovett https://github.com/tinchoz49/parcel-plugin-surplus this one right now simply doesn't get picked up. I can file a new issue if you'd like (to keep noise down here), but Parcel chokes on .jsx files expecting there to be a react import.

mattbruv commented 3 years ago

Gotta love the javashit ecosystem. Stuff works one day and breaks the next. Great stuff from a tool that's supposed to minimize the BS from the JS world

devongovett commented 3 years ago

@Qix- yeah, Parcel 1 plugins don't work with Parcel 2. The plugin API has changed a lot. That plugin looks relatively simple though, so should be fairly easy to port over. Here's some docs for Transformer plugins: https://v2.parceljs.org/plugin-system/transformer/

Qix- commented 3 years ago

@devongovett thanks, I'll give it a look and write a port. :)

EDIT: I gave up on Parcel entirely. Too broken, too much of a headache. See #5974 for my journey of porting things to v2 (it didn't end up well).

boldium-eric-mikkelsen commented 3 years ago

I would encourage folks to try out v2 as it's much more stable and actively maintained whereas v1 has been unmaintained for some time. Personally, I don't use v1 in any of my projects anymore, and v2 is being used in production by some big companies like Adobe and Atlassian. While we are very close to a v2 release candidate, the best way for now is to pin to a recent nightly. If that doesn't work for you, you can try the workaround posted by @nicolo-ribaudo above.

@devongovett , if that's the case, the homepage should reflect this, because right now the instructions on the homepage don't work.

Stradivario commented 3 years ago

Thanks for the fix but lets try v2 again, 4 months since my last try.
Regards for what you have done! :))

EDIT: Just a quick note here.

In production applications or packages i am always fixing the version of the packages due to miss understanding between different people of what patch looks a like.

mherrerabarraza commented 3 years ago

yarn global add parcel-bundler@1.12.3 then run parcel index.html work for me!

For me too, no errors

sjpeterson commented 3 years ago

I have this problem in v2 too.

After upgrading to v2, I still have the problem in docker but not on my host system, despite identical package.json in both environments...

chazzox commented 3 years ago

I'm still having this issue on my GitHub action after pinning both parcel-bundler and preset-env, however the build is succeeding on my local system so I have no idea what's going on. If anyone knows any other fixes let me know

yarn run v1.22.5
$ parcel build index.html --public-url ./
🚨  /home/runner/work/virtuoso-tree/virtuoso-tree/example/index.tsx: Invalid Version: undefined
    at new SemVer (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/node_modules/semver/semver.js:314:11)
    at compare (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/node_modules/semver/semver.js:647:10)
    at lt (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/node_modules/semver/semver.js:688:10)
    at /usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/lib/index.js:276:22
    at Object.default (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/helper-plugin-utils/lib/index.js:22:12)
    at getEnvPlugins (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/env.js:62:34)
    at getEnvConfig (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/env.js:12:25)
    at async getBabelConfig (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/config.js:32:19)
    at async babelTransform (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/transform.js:6:16)
    at async JSAsset.pretransform (/usr/local/lib/node_modules/parcel-bundler/src/assets/JSAsset.js:83:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: Process completed with exit code 1.

Files used Package File Action Workflow

bemnlam commented 3 years ago

I'm still having this issue on my GitHub action after pinning both parcel-bundler and preset-env, however the build is succeeding on my local system so I have no idea what's going on. If anyone knows any other fixes let me know

yarn run v1.22.5
$ parcel build index.html --public-url ./
🚨  /home/runner/work/virtuoso-tree/virtuoso-tree/example/index.tsx: Invalid Version: undefined
    at new SemVer (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/node_modules/semver/semver.js:314:11)
    at compare (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/node_modules/semver/semver.js:647:10)
    at lt (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/node_modules/semver/semver.js:688:10)
    at /usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/preset-env/lib/index.js:276:22
    at Object.default (/usr/local/lib/node_modules/parcel-bundler/node_modules/@babel/helper-plugin-utils/lib/index.js:22:12)
    at getEnvPlugins (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/env.js:62:34)
    at getEnvConfig (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/env.js:12:25)
    at async getBabelConfig (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/config.js:32:19)
    at async babelTransform (/usr/local/lib/node_modules/parcel-bundler/src/transforms/babel/transform.js:6:16)
    at async JSAsset.pretransform (/usr/local/lib/node_modules/parcel-bundler/src/assets/JSAsset.js:83:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: Process completed with exit code 1.

Files used Package File Action Workflow

Have you try to change from "parcel": "^1.12.3" to "parcel": "1.12.3" in package.json?

chazzox commented 3 years ago

Have you try to change from "parcel": "^1.12.3" to "parcel": "1.12.3" in package.json?

Whoops, did that earlier but I must have reverted the commit. Updated the package file now, still doesn't build correctly

Edit: I reworked my action workflow and it is now fixed, I think it was to do with the caching I was using for installing my dependencies.

katzmo commented 3 years ago

Parcel 2.0.0-beta.1 seems to work fine with nodejs v12.18 but has the same issue from nodejs v12.20 onwards (tested with 12.20.1, 12.21.0, 14.16.0).

Real fix seems to be to not use the beta release but a nightly build newer than November :roll_eyes:

Offirmo commented 3 years ago

I would encourage folks to try out v2 as it's much more stable and actively maintained whereas v1 has been unmaintained for some time. Personally, I don't use v1 in any of my projects anymore, and v2 is being used in production by some big companies like Adobe and Atlassian.

@devongovett mate, could you blog about that? Could you write this on the landing page of the website of parcel.js? Could you give a clear link to the blog on the landing page? I really like parcel.js but without official comms, I'm feeling that the project is unmaintained (last blog - hard to find - is from June 2020). I'm considering snowpack ATM.

If the project is active and maintained, please give reinsurance on the website and evidence of activity! Thanks.

(I really love parcel.js and would like to keep it if possible)

nicolo-ribaudo commented 3 years ago

@Offirmo If you look at the recent commits (https://github.com/parcel-bundler/parcel/commits/v2), you can see that the maintainers are quite active!

sadrahkm commented 3 years ago

I still have this problem...

hispanic commented 3 years ago

I was successfully able to move past this after upgrading to Parcel v2. The work-around posted by @nicolo-ribaudo did not work for me (using NPM). It simply led to an additional downstream error:

Cannot read property 'length' of undefined
     at lineCounter (.....node_modules/parcel-bundler/src/utils/lineCounter.js:3:30)

Thank you to @devongovett for the encouragement to pursue the upgrade path and to the contributors for making the Parcel v2 docs readily accessible (even though they are obviously not ready for prime time).

FWIW, the upgrade was fairly straight-forward for me. I had to change --out-dir to --dist-dir and --log-level 4 to --log-level verbose, which was no biggie. However, I did get tripped-up by Parcel v2 in that, by default, it does not generate JavaScript that is ES5-compliant. As such, I had to add the following to my package.json:

"browserslist": ["defaults", "ie 9", "ie 10"]

It may or may not also be important for me to mention that I upgraded Node (from v14.15.4 to v15.11.0) and NPM (from v6.14.10 to v7.6.0) along with Parcel. With NPM v7, specifying the --no-save flag with npm install prevents modifications to package-lock.json. If I had already been on NPM v7, this Invalid Version: undefined error would have been less impactful.

steowens commented 3 years ago

This is my first exposure to Parcel, and I am getting this error. have to say not very impressed. 11 days for a breaking change, when the fix has been identified already? Particularly since parcel 1.12.3 introduces 4 vulnerabilities (2 high, 2 critical)

metagrapher commented 3 years ago

If Parcel is throwing an error, then the solution is to pin Parcel to the previous version, not to pin Babel to fix a misbehaving Parcel.

I eagerly await a fixed Parcel. Perhaps 1.12.5 will be a working version. 🤞🏼

DeMoorJasper commented 3 years ago

@metagrapher we take the babel version you define in your package, which is also the recommended way to do this... so blaming parcel for a breaking babel version isn't really correct.

On the other side as already mentioned Parcel 2 does not have this issue and is over 2x faster than Parcel 1 and will have a rc release soonish...

Pinning a fixed babel version is pretty easy as well as already mentioned in this issue...

Also for anyone who just complains without actually providing any additional way to solve this or context, just use the 👍 on the issue, no need to spam an issue... Especially as there's been a bunch of solutions that have already been suggested: Pinning Babel, updating Parcel, ...

fedegratti commented 3 years ago

I would encourage folks to try out v2 as it's much more stable and actively maintained whereas v1 has been unmaintained for some time. Personally, I don't use v1 in any of my projects anymore, and v2 is being used in production by some big companies like Adobe and Atlassian. While we are very close to a v2 release candidate, the best way for now is to pin to a recent nightly. If that doesn't work for you, you can try the workaround posted by @nicolo-ribaudo above.

@devongovett My company has been using parcel 1 with many projects for a year now. Months ago we decided to move one project to parcel 2 because we needed to build the project as a module. We found that GLSL Transformer was missing, so I encouraged myself to build it and make a pull request. After that, we were able to use parcel 2 for that project without any issue. So far so good. Days ago, when this "invalid Version: undefined" error came, we thought it was a good time to move all projects to v2 (we were waiting for at least a new beta, but that never happened). After we move 2 or 3 projects, we ran into #4332, so we had to rollback to v1. It is really important for us to have the ability to detect changes in linked dependencies, because we have a core library that is used by almost all our projects, and sometimes we need to do changes in this core and see these changes reflected in the project instantly. So, from our point of view, v2 is not mature enough yet.

metagrapher commented 3 years ago

@metagrapher we take the babel version you define in your package, which is also the recommended way to do this... so blaming parcel for a breaking babel version isn't really correct.

On the other side as already mentioned Parcel 2 does not have this issue and is over 2x faster than Parcel 1 and will have a rc release soonish...

You mention above that there are breaking changes between version 1 and version 2. Version 2 is not production ready. Therefore, this is not a path.

It sounds like you do not wish to support your older code which you recently broke with an update, and instead want everyone to rewrite their codebase to upgrade, when this is not always an option, especially if there are breaking changes between version 1 and version 2

The only solution here is to fix the offending code. It certainly is NOT to pin another dependency to fix this one.

nicolo-ribaudo commented 3 years ago

Note that all this breakage is not caused by a Parcel upgrade.

Parcel was calling a Babel plugin as if it was a function, passing an incomplete fake "babel API" parameter. The Babel plugin started relying on some API which are normally present, but not in this "fake API object" that Parcel uses to simulate a Babel execution context.

Thus, even if the ultimate problem is that Parcel 1 uses a Babel plugin in the wrong way, all of this was caused by a Babel upgrade.

devongovett commented 3 years ago

You mention above that there are breaking changes between version 1 and version 2. Version 2 is not production ready. Therefore, this is not a path.

v2 is production ready. As I mentioned before it is being used in production. AFAIK none of the Parcel maintainers are using v1 anymore in any projects. We're trying to push users to switch to v2 because v1 isn't really maintained anymore. v2 is much more stable, performant, and reliable than v1 in pretty much every way. I understand that it's frustrating to need to spend time upgrading a dependency, and if you don't have time that's fine - there are workarounds in this thread.

I also understand that it can be scary to use a tool with a beta version, but this is really a problem with semver more than anything. "Beta" can mean many different things, and it doesn't necessarily mean unstable. If you adopted Parcel 1.0.0 on day one, it was much less stable than v2 is today (even the current v1 is less stable). If you use v2 like you used v1 you'll likely be totally fine. The reason v2 is still in beta is that some plugin APIs may still change before the final v2 release. If you aren't writing custom plugins you should be fine. The v2 defaults include most things v1 did and much more. Migrating should be fairly straightforward. Basically a few CLI options were renamed and a few other small things. We have a guide here.

And again, I apologize for the problems and the lack of maintenance on the v1 side. Parcel is a project that myself and many of the other contributors work on in their free time, and we're all trying to do the best we can. I hope you can understand.

dougschallmoser commented 3 years ago

npm i -g parcel-bundler@1.12.3

seems to work for the time being

mryellow commented 3 years ago

Thus, even if the ultimate problem is that Parcel 1 uses a Babel plugin in the wrong way, all of this was caused by a Babel upgrade.

Babel people feel differently, but absolutely agree.

devongovett commented 3 years ago

I spent a few hours tonight and released v1.12.5 with a fix for this and some other fake "vulnerabilities" reported by npm audit. I hope that's enough to stop the bleeding for now.

That said, please please please migrate to v2 when you can. It's seriously a ton better. ✨

I've marked the parcel-bundler package as deprecated on npm, which you'll see when installing. Please migrate to the parcel package, which will now install v2 by default rather than v1. I've published a new beta release of v2 so you don't need to use a nightly build, and tagged this as the latest. If you run into issues while migrating, or have any questions at all, please either open a new issue or a discussion. We continue to work towards a final v2 release in the coming months, and would appreciate any feedback you may have.

krnlde commented 3 years ago

v2 is production ready. As I mentioned before it is being used in production. AFAIK none of the Parcel maintainers are using v1 anymore in any projects.

@devongovett so none of them uses linked dependencies or monorepo architectures? Are these legacy projects?

All the projects I've worked in in the last 2 years were lerna or yarn workspaced monorepos. Which is exactly why I still need a v1, despite loving to migrate to v2. (#4332 for reference again)

devongovett commented 3 years ago

so none of them uses linked dependencies or monorepo architectures?

@krnlde Yes most of the projects I work on are using monorepos (mostly via yarn workspaces). As an example, see https://github.com/adobe/react-spectrum which is a monorepo and uses Parcel to build all packages, along with our docs website. #4332 shouldn't affect monorepos, only modules that are symlinked outside the monorepo. With a monorepo, the watcher matches from the root of the repo (where your yarn.lock/.git dir live), so any packages inside there will be watched. If you're having an issue with that, perhaps it is a separate problem (please open a new issue).

g45t345rt commented 3 years ago

For me, I would love to upgrade to parcelv2 but every time I try, I keep getting into problems. Right now, I can't use the most recent version because of a breaking bug like EPERM error https://github.com/parcel-bundler/parcel/issues/4955 So I have to continue using parcelv1.

I feel like parcelv2 is close but not yet ready. Maybe, you guys could provide updates on any upcoming bugs like this one for parcelv1, at least, until you release a stable version covering a majority of use cases.

Thank you for providing us with a performant bundler with limited resources on hand.

Don't need to response. I just wanted to let my thoughts here.

fedegratti commented 3 years ago

Yes most of the projects I work on are using monorepos (mostly via yarn workspaces).

@devongovett Thank you for this! I changed the structure of our boilerplate project with a pseudo monorepo (yarn workspaces + git modules) and it worked perfectly! We've just pulled the trigger, we've moved to parcel 2!

parcel-bundler / parcel

Invalid Version: undefined #5943