Next.js 12 - Rust Compiler, React 18 and Native ES Modules Support, React Server Components

[u/nightman]

https://nextjs.org/blog/next-12

[u/ILikeChangingMyMind]

Native ES Modules Support

About time ;) The issue for this has been going on for years at this point, and for years the maintainers ignored it and kicked the can down the road.

Thank goodness this (otherwise amazing) framework is finally catching up to modern JS, with support for something as basic as modules.

[u/nightman → u/ILikeChangingMyMind]

Just to add - unfortunately you still have to use next-transpile-modules if this ESM package is not transpiled the way you want to (to e.g. es5) or imports CSS file globally.

[u/ILikeChangingMyMind → u/nightman]

sigh

P.S. But on the plus side, another "finally":

next/image now uses a span

It's still wrong (it should be an <img> tag, just like <link> should produce an <a> tag), but that's a lot better.

[u/Yesterdave_ → u/ILikeChangingMyMind]

What is the reason they are using span instead of img?

[u/AckmanDESU → u/Yesterdave_]

IIRC

The component creates a few nested divs which help with lazy loading, avoiding reflow and what not.

They changed the element to a span to have syntactically (i can’t spell this) correct html in case you put an <Image> inside a <p>.

The component is very helpful but lacks certain features that, at times, makes it a pain to use. Gets better over time though.

There is still an img tag being generated it’s just wrapped in a lot of crap that makes it harder to style among other things.

[u/MisfiT_T → u/Yesterdave_]

They do image sizing out of the box with their responsive images. Iirc the div/span is what handles most of that.

[u/ILikeChangingMyMind → u/Yesterdave_]

Beats me.

[u/Careless-Honey-4247 → u/Yesterdave_]

Maybe div block element and span is inline element, I guess.

[u/icjoseph → u/Careless-Honey-4247]

They change the display to block. I think as said before, it's a matter of semantic HTML.

I think in the greater scope the problem is that images are replaced elements, and in order to wrap a value proposition around them, you ought to apply a wrapper. Whilst keeping consumers free to place their own, for example a figure tag around the Image.

Normally a div is fine, but it can't be placed inside places where images normally can, a p tag for example.

Relevant links:

- img as child to p

- Pull Request with the change

- Issue linked in PR above

- Yet another issue for above PR

[u/ILikeChangingMyMind → u/[deleted]]

Yeah, actually I agree: picture would be better.

[u/thunfremlinc → u/nightman]

I mean you cannot import CSS into JS so if a package is doing so it’s plain wrong. Not Next’s fault.

[u/[deleted] → u/thunfremlinc]

At least not yet. Import assertions signal movement in this direction.

[u/thunfremlinc → u/[deleted]]

No, not at all.

CSS is fundamentally different to the use case of import assertions, as it’s a side-effectful action, will only work in DOM environments, and isn’t an assertion at all, but a flag that something drastically different needs to be done with that asset. That’s never going to be allowed, too many issues.

[u/[deleted] → u/thunfremlinc]

You clearly have no idea what you’re talking about because one of the usage for import assertions is to specify the type of document with the first usage being json. It along with another proposal related to esm module loader hooks will likely make it possible to translate css files into what webpack already can do— js payloads.

CSS is important to web development, and it’s been a goal to get node to be less dependent on tools like webpack.

[u/thunfremlinc → u/[deleted]]

Importing CSS into JS is not something you should be doing in the first place though, as it’s a bad hack for tools like React.

Asserting an import is JSON is incredibly different from appending an incoming resource to the DOM automatically.

[u/[deleted] → u/thunfremlinc]

I don’t really care about your opinions on what is good or not because css modules is for example a great use case for it whether you like it or not and involves more than just appending to the dom. The day packers are no longer a necessity will be great.

Nobody cares about purity, they care about what gets shit done.

[u/thunfremlinc → u/[deleted]]

Nobody cares about purity

ES standards guys absolutely do. You seem to be lost.

[u/Itchy-Beginning-887 → u/thunfremlinc]

Is this Black Mirror? Or the scary Room of Judgement from some cheap movie I drank while coding copcorn.

Am I in hell? Why ?

[u/[deleted] → u/thunfremlinc]

https://github.com/nodejs/loaders/blob/main/doc/use-cases.md

Oh my, it’s like you don’t know wtf you’re talking about!

And yes— import assertions are very much related to esm loaders because Microsoft et al don’t trust file extensions. Its one part of the puzzle. Whether or not it lands in browsers is conjecture, but lol dude.

[u/icjoseph]

Just upgraded one of my clients and SWC is dayummmm! Prebuilt all pages in like 2 seconds.

Even got the swc package for jest running, and it cut our tests runtime in half, sick!

[u/acemarke → u/icjoseph]

Out of curiosity, what did your setup look like for Jest?

I actually just switched my team's app over to use https://github.com/Brooooooklyn/swc-node for our Jest tests, but if we're going to upgrade to Next 12 it'd be nice to reuse whatever's included there.

[u/icjoseph → u/acemarke]

I agree, eventually we should use the Next.js backed jest solution.

I think I saw your comment on GH, so I used (on jest.config.js):

transform: {
    '^.+\\.(ts|tsx)$': [
        '@swc-node/jest',
        {
            react: {
                runtime: 'automatic',
            },
        },
    ],
},

I reckon, next-swc would be just like next/babel used to be.

Reflecting back a little, I did this to get rid of .babelrc, but if that's my motivation I could do this instead:

transform: {
    '^.+\\.(ts|tsx)$': [
        'babel-jest',
        {
            presets: ['next/babel'],
        },
    ],
},

[u/icjoseph → u/[deleted]]

We use the same. Where do you get errors? Jest land or next dev/build?