This is a very important addition for many folks including those using ant-design.
Because @zeit/[email protected] is two years old and webpack 5 is close to become a default version, it’s getting more and more challenging to stick with the pre-existing app setup.
@vbudovski have you experimented with antd in your branch?
This is a very important addition for many folks including those using ant-design.
Because @zeit/[email protected] is two years old and webpack 5 is close to become a default version, it’s getting more and more challenging to stick with the pre-existing app setup.
@vbudovski have you experimented with antd in your branch?
@kachkaev Yes, that was my primary motivation for adding less support to NextJS. Works well for me.
Thanks for taking the time to open a PR, in general we recommend opening a RFC first to avoid situations where a PR will not be merged and work could have been avoided.
As said in multiple other threads we're not planning to add support for Less to Next.js. It's not used by a large percentage of apps (approximately 4,75%) and would have to be maintained long-term. For comparison Sass is used by 29.79%, tailwind by 15.34%, antd by 9,08%. It also seems that Less is not actively being worked on in comparison to Sass. Adding Less support would make optimizations like https://twitter.com/shuding_/status/1378086219708473344 significantly more difficult as it would be yet another constraint to account for.
Hi @timneutkens, I understand your point, but Less support would be an important addition to Next.js especially for Ant Design users. At the moment, custom solutions prevent us from switching to Webpack 5.
Could we have a deeper discussion on this topic? Thanks!
important addition to Next.js especially for Ant Design users
Looking at https://ant.design/docs/react/customize-theme#Related-Articles there are multiple ways to use Ant Design with various styling solutions including Sass / CSS. Looking at the statistics I've shared above the Ant Design usage is double that of Less, these two can't be directly correlated because the data is completely anonymous, it's likely that the usage of Less is not entirely made up of Ant Design usage though.
At the moment, custom solutions prevent us from switching to Webpack 5.
Next.js allows you to customize the webpack configuration in any way you want, so you could add less support manually if you really have to use it, in general I would recommend leveraging built-in support for other approaches though.
@timneutkens I'm not seeing any methods in AntD that don't still require less
From the link you shared there is another link at the bottom for
Theming Ant Design with Sass and Webpack - https://gist.github.com/Kruemelkatze/057f01b8e15216ae707dc7e6c9061ef7 which leads to a file which has instructions on how to do this, but it still requires less support. There is nothing I can find on the linked page you shared which suggests a way to use AntD without less support. Am I missing something?
I was hoping this would be merged but doesn't look like it's going to. I honestly understand - Less is not widely used and adding this built in support will add maintenance burden.
Also, seems like AntD is really the major reason for Less support these days. And I hope they'll switch to a CSS-in-JS solution instead.
Since my company uses AntD and this was a blocker for a NextJS migration I created a plugin that adds Less support. It works with webpack5 and behaves exactly like SCSS in terms of CSS modules/errors:
https://github.com/elado/next-with-less
It's a "monkey patch" so it's risky by nature, use wisely.
While it makes sense for Next to not adopt Less (even SCSS) a plugin system would be nice. E.g. reviving @zeit/next-less.
Thanks for taking the time to open a PR, in general we recommend opening a RFC first to avoid situations where a PR will not be merged and work could have been avoided.
As said in multiple other threads we're not planning to add support for Less to Next.js. It's not used by a large percentage of apps (approximately 4,75%) and would have to be maintained long-term. For comparison Sass is used by 29.79%, tailwind by 15.34%, antd by 9,08%. It also seems that Less is not actively being worked on in comparison to Sass. Adding Less support would make optimizations like https://twitter.com/shuding_/status/1378086219708473344 significantly more difficult as it would be yet another constraint to account for.
Thanks for the stats, @timneutkens. I understand your reluctance to add yet another preprocessor to the mix, but ~10-12% total Less usage seems quite significant. I assume the remaining 40% is plain CSS? I don't have particularly strong feelings about SCSS vs Less, but antd really doesn't provide any other option at the moment.
As an alternative option, would it be possible to provide a hook into the CSS pipeline so that we could add pre/post-processing steps? Yes, it's possible to add any custom config you like in next.config.js, but it then it's non-trivial to get properly optimised bundles. The monkey-patching implementation provided by @elado works, but is brittle and likely to break.
@timneutkens I cannot find reading all those links articles a way to theme antd without integrating less at some point in the config. If anyone has an approach please share. This is really tough because basically this means I will have to freeze upgrading Nextjs.
I require less as most folks using antd (with any theming) do, which means I need custom webpack or next-less. Utilizing custom webpack or next-less turns off built in CSS support. We have third party components with CSS, which means in order to get that CSS support in Next, I am forced to use next-css, which means I can't upgrade. Is there a way around this predicament that I am missing? Your time and guidance is greatly appreciated, next is an incredible framework and I don't want to have to stop using it, but I cannot ditch my entire UI component library.
@timneutkens, AntD is now the best solution for so many. And it would be very good if you did not add less, but there was a solution for this question .. We need not just add styles, but the ability to change default variables, and so on.
So the next-less plugin is deprecated? If so, that should be clearly marked as such on the plugin's README:
https://github.com/vercel/next-plugins/tree/master/packages/next-less
I can put a PR there if the docs need to be updated.
We made a decision to migrate to Next.js despite having a large amount of Ant Design / Less assets because during the tech selection process we saw the Less plugin as well as examples on your repos for Ant design . I suppose we should have noticed the lack of .less files in the styles directory, and the fact the plugin hasn't been updated in 2 years. Still, a direct deprecation notice would be appropriate, imo.
I guess I also don't understand why customizing our webpack config has to disable the built-in CSS support. Afaik, if configured properly, the less-loader can be dumbed down to just perform a .less to .css conversion; at which point can't the CSS be chained into whatever magic Next.js has? (i.e. from Next's point of view it doesn't have to support or know the files have been transpiled).
@adamyonk - thanks. I will give it a try. I see that one mentioned up higher in the thread.
Another friend of mine pointed me to https://github.com/solidzoro/next-plugin-antd-less which also appears to be maintained.
I'll try both next week and see if either has any "gotchas" - from the docs they look quite similar.
Adding Less support would make optimizations like https://twitter.com/shuding_/status/1378086219708473344 significantly more difficult as it would be yet another constraint to account for.
@timneutkens I can understand the reasoning behind not wanting to support yet another feature in Next.js. However, supporting Less out of the box would make Next.js more compatible with UI frameworks like Ant.Design (which only export their styles as Less).
In the case of Ant.Design, it would also make Next.js more performant.
Perhaps you'll reconsider?
A few relevant points:
Using Ant.Design with Next.js forces a choice between performance or convenience – either (a) add Less support to Next.js yourself (the antd babel plugin should tree-shake modules which import unneeded *.less files), or (b) import the precompiled global antd CSS stylesheet (and incur the load-time performance penalty)
Writing a custom Ant.Design theme requires importing their Less files
The Ant.Design team has been resistant to several past suggestions to switch away from using Less (understandable – it would involve a lot of work for them)
Ant.Design's popularity continues to grow… and so too does the number of developers affected by this issue! 😅
Using stats cited earlier in this thread, Less is used either directly or indirectly by somewhere between 9.08% – 13.83% of Next.js apps
It's probably worth noting that I'm typically a steadfast advocate of CSS-in-JS approaches. However, I'm advocating for Less support here as a pragmatic solution to improving the performance and themeability of Ant.Design when used along with Next.js.
(Aside: Here are some interesting stats on UI framework popularity, as contrasted with both Next.js and Gatsby)
Adding Less support would make optimizations like https://twitter.com/shuding_/status/1378086219708473344 significantly more difficult as it would be yet another constraint to account for.
@timneutkens I can understand the reasoning behind not wanting to support yet another feature in Next.js. However, supporting Less out of the box would make Next.js more compatible with UI frameworks like Ant.Design (which only export their styles as Less).
In the case of Ant.Design, it would also make Next.js more performant.
Perhaps you'll reconsider?
A few relevant points:
1. Using Ant.Design with Next.js forces a choice between performance or convenience – either (a) add Less support to Next.js yourself (the [antd babel plugin](https://github.com/ant-design/babel-plugin-import) should tree-shake modules which import unneeded `*.less` files), or (b) import the precompiled global antd CSS stylesheet (and incur the load-time performance penalty)
2. Writing a custom Ant.Design theme _requires_ importing their Less files
3. The Ant.Design team has been resistant to several past suggestions to switch away from using Less (understandable – it would involve _a lot_ of work for them)
4. Ant.Design's popularity continues to grow… and so too does the number of developers affected by this issue! 😅
5. Using stats cited [earlier](https://github.com/vercel/next.js/pull/23185#pullrequestreview-647986468) in this thread, Less is used either _directly or indirectly_ by somewhere between 9.08% – 13.83% of Next.js apps
It's probably worth noting that I'm typically a steadfast advocate of CSS-in-JS approaches. However, I'm advocating for Less support here as a pragmatic solution to improving the performance and themeability of Ant.Design when used along with Next.js.
(Aside: Here are some interesting stats on UI framework popularity, as contrasted with both Next.js and Gatsby)
I would like to add that if you do not do full support out of the box, then create an official package for working with Ant.Design. with future compatibility, and where people could contribute
Ant has reached a point where it cannot be ignored, unfortunately they offer very little customisation options , the only reaonable way to customise it is via supporting less transpiling and overriding variables
We're also interested in LESS support with nextJS. Currently, we are in an early phase of adoption with a size-able pre-existing base written in .less files. Not being able to import / use *.less with nextJS would be a significant friction point for adoption (IE, we want to re-use our currently existing styles in the new nextJS project).
Well several months after initially thinking this was going to be an issue and looking into various 3rd party solutions for this, we have simply decided to take on disabling "built-in CSS support" from Vercel / Next.js.
Our decision to use Next in the first place was about the opinionated, and useful file-based routing system and /api route simulation for local development. In production we only leverage the SSG capability of Next.
Our code base is shared by multiple webpack / build chains, so interoperability and code re-use trumps any concerns about bundle efficiency and page load times -- the app is fast enough.
One other big perk is we can break other "opinionated rules" enforced by Next: I can import global CSS files anywhere I want! 💥
The config change is fairly simple and vanilla for CSS / CSS Modules / LESS support all in one:
(using Next v12, Webpack 5, AntD 4.17, CSS Loader 5.1.3, Less Loader 8.1.1)
next.config.js
config.module.rules.push({
test: /\.(css)$/,
use: [
MiniCssExtractPlugin.loader,
'css-loader'
]
},
{
test: /\.(less)$/,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
{
loader: 'less-loader',
options: {
lessOptions: {
javascriptEnabled: true,
math: 'always'
}
}
}
]
});
config.plugins.push(new MiniCssExtractPlugin({
filename: 'static/[name].css' // this is the secret sauce to play nice with the Next dev server
}));
Both local development and our SSG output appears perfectly functional with this configuration, and our AntD components are looking mighty fine (huge CSS bundles though! -- I blame Ant)
I wonder if there's any way to hide this warning? 🤔
Warning: Built-in CSS support is being disabled due to custom CSS configuration being detected.
Thanks everyone for the thoughtful comments here. Unfortunately, after discussing with the team once more, we're even more convicted that we cannot increase surface area with built-in support for Less, so I'm going to close this PR once again.
While I understand the workarounds are not ideal for the folks who are depending on Ant Design, we have to weigh tradeoffs when we consider each addition, and in this case, the benefits really don't outweigh the costs.
We'd love to see Ant Design make some tweaks to their outputs in order to make it easier to use Ant Design with Next.js, but for now, it's best to continue to work around this limitation in your own codebase.
FYI ant design 5 moved away from less so it should not be an issue for ant
design users if you use version 5 and above.
On Tue, May 9, 2023, 8:18 AM Tim Neutkens @.***> wrote:
Thanks everyone for the thoughtful comments here. Unfortunately, after
discussing with the team once more, we're even more convicted that we
cannot increase surface area with built-in support for Less, so I'm going
to close this PR once again.
While I understand the workarounds are not ideal for the folks who are
depending on Ant Design, we have to weigh tradeoffs when we consider each
addition, and in this case, the benefits really don't outweigh the costs.
We'd love to see Ant Design make some tweaks to their outputs in order to
make it easier to use Ant Design with Next.js, but for now, it's best to
continue to work around this limitation in your own codebase.
next.js copied to clipboard
vercel
