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

Improve dev DX in Next.js #2701

Closed
steida opened this issue May 5, 2024 · 1 comment
Closed

Improve dev DX in Next.js #2701

steida opened this issue May 5, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@steida
Copy link

steida commented May 5, 2024

What is the problem this feature would solve?

Related https://vercel.com/blog/how-we-optimized-package-imports-in-next-js

Effect lib should be part of this list:

https://github.com/vercel/next.js/blob/c9291d6dd57e08c525733b7187a3b4256bc5f8af/packages/next/src/server/config.ts#L833

I suppose they would happily accept PR for that.

What is the feature you are proposing to solve the problem?

Faster dev mode

What alternatives have you considered?

No response

@steida steida added the enhancement New feature or request label May 5, 2024
ijjk added a commit to vercel/next.js that referenced this issue May 16, 2024
### What?

Adding packages from the Effect ecosystem to the list of
optimized-by-default imports

### Why?

Effect usage includes very liberal use of `import * as Module from
"effect/Module"` and `import { Module } from "effect"`. This is usually
trees-shaken but in nextjs we must declare it to be optimized to be have
this way. To provide a better experience to users I added all the
packages in the ecosystem to the list that are possibly relevant. I
don't expect all of them to get in, but the proposal should start from
the full set of possible candidates. Not included are `/cli`,
`/printer`, `/printer-ansi`, and `/vitest`.

At the very least `effect` and `/schema` should be added for their
prevalence, but even if there is hesitance I recommend adding
`/platform` and `/platform-node` since it's natural for effect usage to
grow into benefitting from these quickly enough.

Related issue in the effect repo 
Effect-TS/effect#2701

cited source for taken action:
[the vercel
blog](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js)

### How?

Adding strings to a set

Co-authored-by: JJ Kasper <[email protected]>
panteliselef pushed a commit to panteliselef/next.js that referenced this issue May 20, 2024
### What?

Adding packages from the Effect ecosystem to the list of
optimized-by-default imports

### Why?

Effect usage includes very liberal use of `import * as Module from
"effect/Module"` and `import { Module } from "effect"`. This is usually
trees-shaken but in nextjs we must declare it to be optimized to be have
this way. To provide a better experience to users I added all the
packages in the ecosystem to the list that are possibly relevant. I
don't expect all of them to get in, but the proposal should start from
the full set of possible candidates. Not included are `/cli`,
`/printer`, `/printer-ansi`, and `/vitest`.

At the very least `effect` and `/schema` should be added for their
prevalence, but even if there is hesitance I recommend adding
`/platform` and `/platform-node` since it's natural for effect usage to
grow into benefitting from these quickly enough.

Related issue in the effect repo 
Effect-TS/effect#2701

cited source for taken action:
[the vercel
blog](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js)

### How?

Adding strings to a set

Co-authored-by: JJ Kasper <[email protected]>
@mikearnaldi
Copy link
Member

closed by vercel/next.js#65465

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants