Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't use [chunkhash] for files #4255

Closed
barrysteyn opened this issue May 2, 2018 · 2 comments · Fixed by #14279
Closed

Can't use [chunkhash] for files #4255

barrysteyn opened this issue May 2, 2018 · 2 comments · Fixed by #14279

Comments

@barrysteyn
Copy link

With next v6.0.0, there is a manifest plugin written by @timneutkens. It should allow one to alter the webpack filenames like this in next.config.js:

const withHashedOutput = (nextConfig = {}) => {
  return Object.assign({}, nextConfig, {
    webpack(config, options) {
      if (!options.defaultLoaders) {
        throw new Error(
          'This plugin is not compatible with Next.js versions below 5.0.0 https://err.sh/next-plugins/upgrade'
        );
      }

      console.log(config);
      config.output.filename = isProduction ? '[name][chunkhash]' : '[name]';

      if (typeof nextConfig.webpack === 'function') {
        return nextConfig.webpack(config, options);
      }

      return config;
    }
  });
};
const config = withHashedOutput({});
module.exports = config;

NOTE: I have overridden _document.js

Expected Behavior

I would expect all file names to be hashed, and for next to have a proper mapping from the original file name to the hashed filename.

Current Behavior

_document.js is excluded from this mapping, so things fail.

Steps to Reproduce (for bugs)

  1. Alter next.config.js by using the code pasted at the start of this bug
  2. Note that files have hashes in them after this alteration (look in the .next folder)
  3. Next will crash since it can't find _document

I have a suspicion (although unconfirmed) that _error and _app will also suffer from this (if overridden).

@timneutkens
Copy link
Member

Doing:

config.output.filename = isProduction ? '[name][chunkhash]' : '[name]';

Is currently not supported, since you're changing the output of all files, instead of specific ones you're generating.

Adding hashes to page files is going to be up to us the future.

The pages-manifest.json wasn't added as a way to support , instead it was added as a way to speed up page resolving.

We don't ship this manifest to the client side, that's why pages can't be hashed like this.

@barrysteyn
Copy link
Author

Hi Tim

Do you think this would be a nice feature? What is your estimated level of effort to get this going? If not incredibly high, I am thinking of implementing it myself?

@lock lock bot locked as resolved and limited conversation to collaborators May 2, 2019
kodiakhq bot pushed a commit that referenced this issue Jun 20, 2020
Updates the way filenames are generated for browser compilation.
Notably:
- All entry bundles now have hashes in production, this includes pages (previously pages used a buildId in the path)
- The AmpFiles no longer depends on hardcoded bundle names, it uses the buildManifest instead (internals)
- All cases where we match the page name from the chunk/entrypoint name now use the same function `getRouteFromEntrypoint` (internals)
- In development we no longer include the "faked" `buildId` set to `development` for page files, instead we just use the `/_next/static/pages` path (was `/_next/static/development/pages`). This was changed as it caused unneeded complexity and makes generating the bundles easier (internals)
- Updated tons of tests to be more resilient to these changes by relying on the buildManifest instead of hardcoded paths (internals)

Follow up of these PRs:
#13759
#13870
#13937
#14130
#14176
#14268


Fixes #6303
Fixes #12087 
Fixes #1948
Fixes #4368
Fixes #4255
Fixes #2548
rokinsky pushed a commit to rokinsky/next.js that referenced this issue Jul 11, 2020
Updates the way filenames are generated for browser compilation.
Notably:
- All entry bundles now have hashes in production, this includes pages (previously pages used a buildId in the path)
- The AmpFiles no longer depends on hardcoded bundle names, it uses the buildManifest instead (internals)
- All cases where we match the page name from the chunk/entrypoint name now use the same function `getRouteFromEntrypoint` (internals)
- In development we no longer include the "faked" `buildId` set to `development` for page files, instead we just use the `/_next/static/pages` path (was `/_next/static/development/pages`). This was changed as it caused unneeded complexity and makes generating the bundles easier (internals)
- Updated tons of tests to be more resilient to these changes by relying on the buildManifest instead of hardcoded paths (internals)

Follow up of these PRs:
vercel#13759
vercel#13870
vercel#13937
vercel#14130
vercel#14176
vercel#14268


Fixes vercel#6303
Fixes vercel#12087 
Fixes vercel#1948
Fixes vercel#4368
Fixes vercel#4255
Fixes vercel#2548
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants