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

Process custom server code through Webpack #3870

Closed
1 task done
smithki opened this issue Feb 22, 2018 · 5 comments
Closed
1 task done

Process custom server code through Webpack #3870

smithki opened this issue Feb 22, 2018 · 5 comments

Comments

@smithki
Copy link

smithki commented Feb 22, 2018

Now that universal Webpack (#3578) is released, there's a great opportunity to streamline custom servers using Next. Having the ability to write in a consistent syntax (whether ES6+ or TypeScript) between client and server code would greatly benefit the developer experience. I find it sort of awkward that a custom server entry point has to remain compatible with whatever your current version of Node is. I created a work-around as a Next plugin, but I find it hacky and awkward. I can't imagine it would be too much work to build a server bundle separately from the client bundle. What can I do to help this along?

  • I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

When I run next dev or next start, my custom server is bundled via Webpack and served, enabling consistent syntax across the client and custom server code.

Current Behavior

A custom server is started using node ./path/to/server.js, so Webpack never touches it.

Context

I usually write in TypeScript, so bundling Next custom server code through Webpack would enforce consistent syntax in my code base and eliminate my dependency on ESLint or Babel.

Your Environment

Tech Version
next ^5.0.0
node 8.7.0
OS macOS 10.13.3
browser Firefox 58.0.2
etc N/A
@timneutkens
Copy link
Member

I've explained this is nearly all issues about this (there are multiple), but it's not possible to compile the server for the simple reason that the server starts webpack in development mode. However someone made a similar solution to yours that's using nodemon and tsc directly to compile the server: https://github.com/zeit/next.js/tree/canary/examples/custom-server-typescript

@smithki
Copy link
Author

smithki commented Feb 23, 2018

I've explained this is nearly all issues about this (there are multiple)

Sorry, obviously I didn't conduct a thorough-enough search. Outside of #1245, I haven't found significant discussion around this. For my specific use-case, I thought it warranted a new issue. I apologize for adding work to your plate.

it's not possible to compile the server for the simple reason that the server starts webpack in development mode.

Right, makes sense, but couldn't Webpack also run separately for server-side code? Kind of like how React Universally does it? It's just an idea... I think it might make for a nicer dev experience that requires less boilerplate. One thing I really like about Next is that it's super easy to get started. For custom servers, you effectively have to write a build system yourself. :( Next already has an awesome Webpack configuration, I'd rather just use it!

@timneutkens
Copy link
Member

Sorry, obviously I didn't conduct a thorough-enough search. Outside of #1245, I haven't found significant discussion around this. For my specific use-case, I thought it warranted a new issue. I apologize for adding work to your plate.

No worries, I don't mind explaining it again 😄

Right, makes sense, but couldn't Webpack also run separately for server-side code? Kind of like how React Universally does it? It's just an idea... I think it might make for a nicer dev experience that requires less boilerplate. One thing I really like about Next is that it's super easy to get started. For custom servers, you effectively have to write a build system yourself. :( Next already has an awesome Webpack configuration, I'd rather just use it!

Currently the server and webpack are tightly coupled because we have a feature called on demand entries which compiles only the pages in your app that you visit. It allows for faster startup + less compilation time.

It basically works like this:

If you have 100 pages in your pages directory, and they all took 1 second to compile. You'd have to way 100 seconds for next to start in development mode. Instead, with on demand entries, we only compile the critical bundles (_document, _error and commons (only holding react/react-dom)) and when you go to http://localhost:3000 we'll inject the pages/index.js entrypoint into webpack, webpack compiles it and we server render the response.

In the long term we might refactor this or implement another way of defining server files and compiling them, but it'd involve a major refactor.

I hope this answers your questions 🙏

@smithki
Copy link
Author

smithki commented Feb 27, 2018

I hope this answers your questions 🙏

It does and thank you for an in-depth explanation!

@samkelleher
Copy link

https://github.com/kriasoft/react-starter-kit

This isomorphic react app would be a good reference point as exposes the server and runs both server and webpack through client, webpack is exposed rather than abstracted away underneath something like nextjs. Because the nextjs server starts webpack, it's impossible to setup webpack on a custom server because webpack complains about dual compilers (ie webpack build within a webpack build).

So if the custom server needs something from webpack, such as handling file assets, then it will fail.

The referenced next-custom-server isn't available publicly any longer.

@lock lock bot locked as resolved and limited conversation to collaborators Dec 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants