Update dependency next-transpile-modules to v10

[renovate[bot]]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
next-transpile-modules	2.3.1 -> 10.0.1

---

Release Notes

martpie/next-transpile-modules (next-transpile-modules)

v10.0.1

Compare Source

v10.0.0

Compare Source

Hello everyone! No breaking changes in this version, I just bumped it to make sure people are careful when upgrading to Next.js 13. Please make sure to read the additional notes below regarding the future of next-transpile-modules and Turbopack.

If you appreciate my work, and if you can afford it, you (or better, your company) can show support by sponsoring me (or just buying me a beer 🙌).

Support for Next.js 13

Enjoy!

Experimental support for the app/ directory

Next.js 13 comes with beta support for the new app/ directory, and next-transpile-modules supports it.

Please think twice before using this feature as it's still experimental and next-transpile-modules could break at any of Next.js commit.

Note on Turbopack

Turbopack being in alpha, next-transpile-modules will not be supporting it. It may work out of the box, it may not, I will not work on it before it's more stable.

Note on the future of next-transpile-modules and transpilePackages

Next.js 13 comes with a new option called transpilePackages. This new experimental feature currently allows to transpile local and npm ES modules, so you might not need next-transpile-modules anymore, ifyou're ready to enable experimental features on Next.js.

That said, and this is great news, the Next.js team is working on feature parity with next-transpile-modules, so next-transpile-modules will disappear some day in the future.

There is no clear timeline yet, so in the meantime, I'll keep maintaining this plugin until:

• transpilePackages is not experimental anymore
• transpilePackages has feature parity with next-transpile-modules

That's it!

Take care of yourselves and happy coding!

v9.1.0

Compare Source

• Add TS typings to the plugin (for better autocomplete), thanks @​belgattitude!
• Internal dependencies update

v9.0.0

Compare Source

Chop chop! Next.js 12 yesterday, next-transpile-modules@9 today :] As always the breaking changes are indicated by the ⚠️ icon.

If you appreciate my work, and if you can afford it, you (or better, your company) can show support by sponsoring me (or just buying me a beer 🙌).

Support for Next.js 12

Nothing much to say. You should definitely upgrade, that's an amazing release!

Removed support for Webpack 4 ⚠️

What it says, next-transpile-modules is aligned with Next.js releases, so no more Webpack 4.

Removed support for legacy module resolution ⚠️

If you have seen in your logs with v8 the following warning:

DEPRECATED - fallbacking to previous module resolution system for module "XXX", you can now just pass the name of the package to transpile and it will detect its real path without you having to pass a sub-module.

this is for you.

You can read the 7.1.0 version changelog for a detailed explanation, but basically, what you want to do now is the following:

const withTM = require('next-transpile-modules')([
- 'some/very/specific/file.js'
+ 'some'
]);

v8.0.0

Compare Source

Following the Next.js 11 announcement, next-transpile-modules v8 is here. Technically v7 should work fine, but there was a default change, so I mark this as a major version.

The breaking changes are indicated by the ⚠️ icon.

Webpack 5 enabled by default ⚠️

If you don't have any webpack5 key in your next.config.js, next-transpile-modules will assume you use Webpack 5.

If you already have Webpack 5 enabled, nothing changes for you. If you want to stick with Webpack 4, you can see how to disable Webpack 5 here.

It is of course strongly recommended to upgrade to Webpack 5, as it brings substantial improvements to compilation time!

next-transpile-modules will keep supporting Webpack 4 as long as Next.js does, and we'll gladly kill it with fire when Next.js won't support it no more :)

Cheers!

v7.3.0

Compare Source

• Added support for top-level webpack5 configuration (next@canary)

v7.2.0

Compare Source

• Added support for Global CSS imports from modules located in node_modules (thank you @​fabianishere!)

v7.1.2

Compare Source

• Fixed false-positive deprecation warnings on Webpack 4 setups

v7.1.1

Compare Source

• Fixed new package lookup for packages using exports field
• Fixed code that should have not been shipped yet

v7.1.0

Compare Source

• Added new package lookup resolution
• Deprecated specific package file lookup

When trying to locate the packages you are trying to transpile, since v5, next-transpile-modules tries to resolve your module names you pass to it, which required a valid main or exports field. It will now tries to resolve directly to its package.json.

This should solve the issue for some people who did not want to use the main/exports fields for their local packages, and some others who wanted to use local packages locally while publishing them on NPM as well.

If next-transpile-modules cannot find your package package.json, it will fallback to the previous lookup system (a deprecation warning was added), so no breaking change is expected.

Basically, for the few that were using something like:

const withTM = require('next-transpile-modules')(['some/very/specific/file.js']);

You should now be able to use:

const withTM = require('next-transpile-modules')(['some']);

...and everything will work fine.

v7.0.0

Compare Source

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

v6 works perfectly with [email protected], 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.

v6.4.1

Compare Source

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

Thanks @​jacargentina for helping!

v6.4.0

Compare Source

• 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 https://github.com/martpie/next-transpile-modules/pull/179.

Big big thanks to @​sokra and @​ScriptedAlchemy!

v6.3.0

Compare Source

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

v6.2.0

Compare Source

• 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 [email protected])

v6.1.0

Compare Source

• 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

v6.0.0

Compare Source

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!

v5.0.0

Compare Source

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!

v4.1.0

Compare Source

• 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

v4.0.3

Compare Source

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

Thank you @​anmonteiro!

v4.0.2

Compare Source

• Fix hot-reloading for transpiled packages #​97

Thanks to @​aleksei-savitski-softswiss!

v4.0.1

Compare Source

• Fixed various issues with transpiled CSS/SCSS #​95 #​96

Internal:

• Added yarn workspeces end-to-end test
• Improved end-to-end tests setup

Thank you to everyone who helped debug these issues!

v4.0.0

Compare Source

Added support for Next.js 9.5

This is a breaking change, as the Next.js Webpack configuration was quite changed, and I did not want to maintain a compatibility layer based on the Next.js version. ;) This version is not compatible with next<4.5.0.

So you don't have to do much to upgrade, apart from updating both your next and next-transpile-modules dependencies.

The support for Webpack 5 was also added, please consider it experimental as long as the Webpack 5 integration is experimental in Next.js.

Please report issues if you face any :)

Big thanks to @​ScriptedAlchemy and @​migatech2015 for helping with this release, and all the other persons involved in reviews and advices!

v3.3.0

Compare Source

• Add support for Yarn PnP (Berry) (thanks @​goszczynskip!)

v3.2.0

Compare Source

• Add support for .mjs files (thanks @​BRKalow!)

v3.1.0

Compare Source

• Add support for Next.js 9.3's Sass/Scss features: you can now transpile Sass or Scss from node_modules

v3.0.2

Compare Source

• Fix build crash when using the plugin with an empty array

v3.0.1

Compare Source

• Fix module import when relying on package.json's main field (big thanks to @​TrySound)

v3.0.0

Compare Source

next-transpile-modules-3.0 introduces some important new features, bugfixes, and a minor breaking change. The breaking changes are indicated by the ⚠️ icon.

If you face problems with this new version please open an issue :)

⚠️ New plugin invocation

To avoid polluting the global config object with the transpileModule property, next-transpile-modules now exposes a function that takes an array of strings (the modules you want to transpile) as its first parameter.

In action:

// next.config.js
- const withTM = require('next-transpile-modules');
+ const withTM = require('next-transpile-modules')(['somemodule', 'and-another']);
 
module.exports = withTM({
-  transpileModules: ['somemodule', 'and-another']
});

This notation was inspired by @next/bundle-analyzer.

Added support Next.js 9.2 CSS features

In [email protected] was added support for CSS files (as CSS modules or global CSS). next-transpile-modules will now let your transpiled packages include CSS, and will allow you to import global CSS in pages/_app.js.

More details are available in the documentation.

Bugfixes

Potentially breaking bugfixes depending on your setup:

• ⚠️ a transpiled module whose name was a substring of another module (let's call it A) won't make A to be transpiled anymore

For example: transpiling core won't make core-js to be transpiled too anymore.

• ⚠️ nested node_modules directories are now correctly ignored.

For example, if you want to transpile @shared/ui, @share/ui/node_modules/lodash won't get transpiled anymore.

Misc

• Unit-tests were refined to handle some edgecases
• End-to-end tests were added to ensure developing/refactoring this plugin with more confidence
• Added Prettier

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• [ ] If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.