7.0.0

Bonsoir! 👋 Following the release of Next.js 10.2, next-transpile-modules@7 is here!

v6 works perfectly with next@10.2.0, v7 only introduces an option default value change.

The breaking changes are indicated by the ⚠️ icon.

⚠️ resolveSymlinks: true by default

If you are using yarn/npm workspaces, it should not change anything, but compilation time and reloads will be faster.

If you are using npm/yarn link or npm's file:, you will need to set the option to false if you get compilation errors.

Webpack 5 support

Webpack 5 support is not experimental anymore! It will be disabled by default though, because this plugin updates the Next.js Webpack configuration. So if you want to use Webpack 5 (and enjoy all the bundles/compilation improvements), you'll need to explicitly enable it in your config:

// next.config.js
const withTM = require('next-transpile-modules')(['...']); 

module.exports = withTM({
  future: {
    webpack5: true,
  },
});

I would like to thank everyone who helped working on that, you guys are absolutely awesome.

Fixed nested modules transpilation

Sometimes you want to transpile a nested modules, the following now works correctly:

const withTM = require('next-transpile-modules')(['some-deps', 'some-deps/node_modules/some-sub-deps']); 

TS declaration files

JSDoc was already provided for the best auto-completion experience possible, but next-transpile-modules now comes with .d.ts files in order to provide typings for those with custom setup using a next.config.ts.

They are not perfect though, so feel free to contribute to them if you want better typings.

6.4.1

• Fixed Reference Error: module is not defined for some packages + Webpack 5

Thanks @jacargentina for helping!

6.4.0

• Improved performances for Webpack 5 users
• Improved performances for users using not using link: or file: (you might want to set resolveSymlinks to true, cf. documentation)
• Improved some FAQ points

If you're curious about these changes, you can have a look at #179.

Big big thanks to @sokra and @ScriptedAlchemy!

6.3.0

• Improved package resolution for some advanced package.json exports usecases

6.2.0

• Fixed some issues with nested node_modules
• Fixed scoped packages transpilation on Windows
• Fixed Webpack 5 with Next.js 10.0.6
• Update tested Next.js version to 10.0.6

⚠ Webpack 5 users 👇

• unstable_webpack5 has been removed, please use future: { webpack5: true } in your next.config.js instead (requires next@10.0.6)

6.1.0

• Added support for module field in package.json
• Improved do not transpile nested node_modules (node_modules in node_modules)
• Improved dependencies hell (less dependencies when installing the plugin)
• Improved some FAQ points

6.0.0

Hello there 👋

shortly after the release of v5, here's v6, which solves some edgecases when transpiling modules. Again, no API changes, I still consider it major version as your build might break with this release.

The breaking changes are indicated by the ⚠️ icon.

Coming from v4? -> Please read the changes of v5 first ;)

⚠️ Fixed resolution strategy for packages resolving their main field to a sub-directory

Let's say a module/package is as follows:

styleguide/
    components/
    utils/ 
    package.json # <- `main` field resolving to components/index.js 

with v5, then only styleguide/components would get transpiled, and styleguide/utils/ would get ignored.

In v6, the behavior is similar to v4: everything in styleguide will get transpiled: components/ and utils/.

We lose granularity, but we get a much better DX out-of-the-box, and it matches the behavior of v4. This should solve most of the issues that you may have faced with v5.

Thanks to everyone who helped me test this 🙌

cheers!

5.0.0

Hello there, next-transpile-modules@5 is here! There are no API changes, but some internal changes introduced breaking behavioral changes.

Make sure you understand the changes before upgrading!

The breaking changes are indicated by the ⚠️ icon.

⚠️ New resolution strategy

next-transpile-modules used to use Regexes to make Webpack check if a file should be transpiled by Babel or not. This is not the case anymore.

The plugin now uses require.resolve (enhanced-resolve actually) to check which paths should be transpiled or not.

Ok, what does that mean for you as a developer?

• Ensure all your transpiled modules have a main field
  • If you think it does not make sense, still, have one! You can also create an empty index.js at the root and point "main" to it
  • This main field can point to anything that is a module, that means you can point to a TS file: "main": "src/index.ts"
• If you are making use of the undocumented custom regex support (like require('next-transpile-modules')(['@org/(.*)'], this won't work anymore. There is no plan of re-adding this "feature" right now.
• next-transpile-modules will use the dirname of the modules resolve in your main field as "the folder that needs to be transpiled". Meaning that if you have the following structure:

styleguide/
├── components/
├── utils/
└── package.json

and your main field is components/index.js, utils/ won't get transpiled.

After that, you should be good to go!

Support for pnpm and Yarn "Berry"'s PnP

Tests were added to make sure everything works with pnpm. Yarn Berry should now also work out of the box.

A few words about Yarn's PnP:

• It was an absolute pain to support. Yes, I really want you to know that. 😅
• HMR may not work (well, your modules are zip files)
• I will need your feedback and help to improve things there: if you need to have a fix fast, it's better if you submit a PR ;)

Debug Mode

A debug mode was added in case you're interested in checking if the correct files get transpiled. Be careful it's verbose!

const withTM = require('next-transpile-modules')(['somemodule', 'and-another'], { debug: true });

Webpack 5 improvements (experimental)

• HMR should now work
• But HMR is not yet fully optimized, due to some Webpack cache configurations that are extremely hard to tweak

Some well deserved thanks

I would like to thank everyone who helped me with this release, let it be testing, feedback, suggestions...

Especially, huge props to @ScriptedAlchemy for pushing and helping so hard with the Webpack 5 support. You should definitely go support his work. Merci à toi Zack!

4.1.0

• Add an options argument to the plugin invocation:
  • resolveSymlinks will resolve the path your symlinked modules (you probably don't want that, but it is useful in some rare occasions)
  • unstable_webpack5 will enable the experimental Webpack 5 support
• ⚠️ the Webpack 5 auto-detection was removed, enable unstable_webpack5 instead

4.0.3

• Fix Webpack 5's externals override in Next.js 9.5.2 (remember: Webpack 5 support is experimental!)

Thank you @anmonteiro!