withastro / roadmap

Ideas, suggestions, and formal RFC proposals for the Astro project.
290 stars 29 forks source link

Production Dependencies #654

Closed robak86 closed 1 year ago

robak86 commented 1 year ago

What version of astro are you using?

2.9.3

Are you using an SSR adapter? If so, which one?

Node

What package manager are you using?

npm

What operating system are you using?

Mac

What browser are you using?

Chrome

Describe the Bug

After installing only production packages (npm i --omit dev) for the project, I noticed that possibly many installed packages are not required for the runtime. They probably should be declared as devDependencies. e.g. typescript, @babel/*, esbuild, vite. Having them declared as dependencies greatly increases the size of node_modules, making, e.g. building a small docker image of the app very difficult. The node_modules for a "hello world" app has about 160 MB.

What's the expected result?

All dependencies that are not required for the runtime should be declared as devDependencies.

Link to Minimal Reproducible Example

https://github.com/withastro/astro/blob/main/packages/astro/package.json

Participation

Princesseuh commented 1 year ago

Those dependencies are all required by astro at runtime. typescript is used for astro check, for instance, so they can't be marked as devDeps or you won't get them when installing astro

What you probably mean is that those dependencies are not required by apps built with astro, which is a different problem that's not really related to our package.json per se

robak86 commented 1 year ago

Thanks for the clarification. I understand that dependencies like typescript are required by the Astro command line app. But you don't use astro check in a project that will be deployed after running astro build. So having, e.g. typescript in devDependencies would still allow users to run Astro CLI in development but wouldn't add additional size to node_modules for the production. The dockerization workflow that I'm thinking about is:

  1. Builder stage

    • copy the project to the Docker context (except for the node_modules)
    • install all packages (including devDependencies)
    • run astro build - CLI works just fine having typescript in devDependencies.
  2. Release stage

    • copy the dist directory from the builder stage
    • install only production dependencies omitting devDependencies. No need for installing e.g. typescript as we will run only node dist/server/entry.mjs

Currently, the last step will also install many dependencies that are not required for node dist/server/entry.mjs to run. However, I'm not sure if this is also the case for other adapters.

Princesseuh commented 1 year ago

So having, e.g. typescript in devDependencies would still allow users to run Astro CLI in development but wouldn't add additional size to node_modules for the production.

No, if typescript was a dev dep of astro, when users install astro in their project they wouldn't get the dev deps

robak86 commented 1 year ago

Yes, you are right. I forgot that devDependencies of 3rd party libraries are not installed. Solving this issue would probably require more significant changes - like extracting CLI into a separate package that the user can add as devDependency. Sorry for the trouble.

Princesseuh commented 1 year ago

Oh, no need to close the issue! This is definitely something we'd want to fix eventually.

I think the best way would probably to actually extrude the runtime part into a separate package and when generating the SSR build, have a package.json with only that package?

natemoo-re commented 1 year ago

I'm transferring this to the roadmap because we'll have to talk about it! I think we'd like to see this happen but exactly how we tackle it remains to be seen.