fix(*): use the full hash to avoid collisions

[ArsenyYankovsky]

↪️ Pull Request

Fixes 3823 and 3747. Switching to Parcel 2 is not an option for us since it's in the Beta and doesn't support multi-target builds. I think it's a pretty critical bug fix and should be fixed in the Parcel 1.

💻 Examples

One example of relative paths that will generate same id is:
../../node_modules/lodash-es/clone.js
../../node_modules/core-js/library/modules/_an-object.js

✔️ PR Todo

• Added/updated unit tests for this change
• Filled out test instructions (In case there aren't any unit tests)
• Included links to related issues/PRs

[height]

This pull request has been linked to 28 tasks:

• T-190 Investigate why a variable is renamed in is-v2-ready-yet causing the graph to be too narrow (unlink task)
• T-294 Codeframe: lines too long for terminal (e.g. require("react") in react-dom) (unlink task)
• T-246 Don't use markdown for filepaths in diagnostic formatter (unlink task)
• T-1 Inline scripts and styles in HTML (unlink task)
• T-295 cli exits before buildFailure diagnostic is printed (unlink task)
• T-398 Source Map Performance improvements (unlink task)
• T-249 Re-enable log deduplication on logger (unlink task)
• T-88 Validate environment properties (context, outputFormat) (unlink task)
• T-208 Track diagnostics in resolver (unlink task)
• T-227 Fix @parcel/cache: #<Promise> could not be cloned in integration tests (unlink task)
• T-74 Inline source maps (unlink task)
• T-373 $init calls weren't imported and run cross-bundle (unlink task)
• T-233 Fix re-exporting in ts types and scope hoisting (unlink task)
• T-93 Build all packages in a monorepo (unlink task)
• T-396 Fix source maps with terser (unlink task)
• T-206 Validate .parcelrc with diagnostics (like targets) (unlink task)
• T-232 Fix asset deferring with library output (unlink task)
• T-302 Replace ink with stdout (unlink task)
• T-185 Handle Tabs properly when rendering a codeframe, converting them to spaces and offsetting highlights if needed (unlink task)
• T-220 Transformation#runPipeline / Pipeline#transform fail if type changes but pipline doesn't (unlink task)
• T-228 Escape HTML in HMR errors (unlink task)
• T-16 Error handling - code frames (unlink task)
• T-163 Add a Logger instance to each plugin call (unlink task)
• T-296 MDX Transformer (unlink task)
• T-404 [T-373] Fix importing wrapped assets from a different bundle #4266 has a race condition (unlink task)
• T-177 update dev and hmr server to properly use diagnostic objects (unlink task)
• T-234 Fix sideEffects: false and commonjs output (unlink task)
• T-15 Yarn PnP (unlink task)

💡Tip: Add "Close T-190" to the pull request title or description, to a commit message, or in a comment to mark this task as "Done" when the pull request is merged.

[DeMoorJasper]

We don't really update parcel 1 anymore, is there any way we can help you transition to Parcel 2 instead?

[ArsenyYankovsky]

I tried switching to Parcel 2 and almost immediately I found a blocking issue for us which is the absence of multi-target builds. I see that it's in the todo list. I don't think it's good to drop support in the form of bug fixes for Parcel 1 until Parcel 2 is released and considered production-ready.

Thanks for a fast response!

[mischnic]

What exactly do you mean by "multi-target builds"? Parcel 1 didn't support this either?
Builds with multiple entry points and/or multiple targets do work. It's just that assigning specific entry points to specific targets isn't possible

[ArsenyYankovsky]

We are running the following command to build our apps: parcel build ./react/apps/*.tsx --no-content-hash which builds all the apps in that directory.

Using parcel@nightly currently with the same command gives me a following error:

Error: Bundles must have unique filePaths

If I just build one of them it gives me files with names like gulpfile.js and gulpfile.css. I guess I need to configure my entries using the programmatic API?

[mischnic]

Error: Bundles must have unique filePaths

This usually happens because you have somehow specified an output path for the output bundle but are using multiple entries (which obviously cannot all have the same output filename).

I guess I need to configure my entries using the programmatic API?

No, does your package.json contain have a main/module/browser field? (Not sure where that gulpfile prefix comes from)

[ArsenyYankovsky]

Thank you very much, I had main entry in my package.json which I removed and now can successfully build.

However, we need to support IE11 and that means using es5 as target. My output files contain arrow functions and I'm not sure why.

My .babelrc:

{
  "presets": [
    [
      "@parcel/babel-preset-env",
      {
        "forceAllTransforms": true
      }
    ],
    "@babel/preset-typescript"
  ],
  "plugins": [
    [
      "@babel/plugin-proposal-decorators",
      {
        "legacy": true
      }
    ],
    [
      "@babel/plugin-proposal-class-properties",
      {
        "loose": true
      }
    ],
    [
      "@babel/plugin-transform-react-jsx"
    ]
  ]
}

My tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es5",
    "noImplicitAny": false,
    "outDir": "./dist",
    "lib": [
      "es5",
      "DOM"
    ],
    "sourceMap": true,
    "listEmittedFiles": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "jsx": "react"
  },
  "esModuleInterop": true,
  "include": [
    "react/**/*"
  ]
}

and my package.json has following section:

  "browserslist": [
    "last 1 version",
    "> 1%",
    "maintained node versions",
    "not dead",
    "IE 10"
  ]

I might've missed something but I can't honestly see why. Thank you again.

[mischnic]

• tsconfig is ignored by @babel/preset-typescript.
• maybe these arrow functions come from node_modules? Your project's babelrc isn't used for npm dependencies.

[ArsenyYankovsky]

Yes, they actually do come from the node_modules. All the arrow functions from my code are transformed correctly. Should I use overrides section in my .babelrc to process my dependencies or is there a nicer way? Thank you again.

[ArsenyYankovsky]

I tried using babel.config.js and babel.config.json instead of my .babelrc to make it a project-wide configuration but that didn't seem to change anything.

[mischnic]

babel.config.* is monorepo-wide, but still not for node_modules.

Ideally, the "includes" field in babelrc would be respected (#1655).

[DeMoorJasper]

I don't actually think node_modules are being transpiled with babel in Parcel 1 either as far as I remember so it's not really different, but we definitely need to support babel's includes at some point

[ArsenyYankovsky]

I think parcel 1 uses babel 6 which transpiles node_modules by default. I tried different things but what seems to have worked is using @babel/register. I will try using it to require all my modules tomorrow and will let you know. Thanks again for great support. You guys are awesome.

[ArsenyYankovsky]

I tried using @babel/register to process my node_modules and it initially complained about reprocessing itself so I ended up ignoring some of the babel and parcel related modules like that:

require('@babel/register')({
  ignore:
    [
      './node_modules/@babel/*',
      './node_modules/@parcel/babel-preset-env/*',
      './node_modules/@parcel/transformer-json/*',
      './node_modules/@parcel/transformer-postcss/*',
      './node_modules/@parcel/transformer-css/*',
      './node_modules/@parcel/packager-js/*',
      './node_modules/@parcel/packager-css/*',
      './node_modules/@parcel/optimizer-cssnano/*',
      './node_modules/@parcel/optimizer-terser/*',
    ],
})

Unfortunately, there are still arrow functions in the resulting file. I'm running build command with the --no-cache flag so there's nothing cached.

[ArsenyYankovsky]

I've worked around by removing a dependency that had arrow functions. I had other issues which I applied various workaround to fix. The last thing I encountered is the optimization being so slow it times out on CI (take more than 10 minutes to optimize css). It's been a hassle to make it work and it still doesn't. I still don't understand why bugfixes for parcel 1 can't be merged, especially since parcel 2 is in this state. Guess I'll switch to webpack.

[DeMoorJasper]

@ArsenyYankovsky Parcel 2 is in a state that is almost as stable as Parcel 1, just lacks a bit of docs and plugin api stability. There's also some issues with cache stability but Parcel 1 also had those...

Not sure how optimizations time out CI especially css, must be quite some codebase if that happens and would probably also happen with webpack...

I also totally agree it's pretty ridiculous that this never has been fixed so far, the original fix for this bug had been created 2 years ago when I encountered it and created a PR. This should've been fixed a long time ago... Back then we also still released Parcel 1 updates...