22 thoughts on “Invalid Version: undefined

  1. 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"
    },
  2. 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.

  3. 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: #5948

  4. @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 #5943 (comment) for NPM users:

    1. 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.
    2. Add "preinstall": "npx npm-force-resolutions" to your scripts in package.json
    3. 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"
      }
    }
    1. 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.

  5. 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)

  6. @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, …

  7. 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.

  8. 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.