-
Notifications
You must be signed in to change notification settings - Fork 368
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
feat: add --prod
flag to dev
command
#5338
Conversation
📊 Benchmark resultsComparing with ab48f8e Package size: 259 MB⬆️ 0.03% increase vs. ab48f8e
Legend
|
src/commands/dev/dev.mjs
Outdated
@@ -710,6 +807,7 @@ export const createDevCommand = (program) => { | |||
.option('-o ,--offline', 'disables any features that require network access') | |||
.option('-l, --live', 'start a public live session', false) | |||
.option('--functionsPort <port>', 'port of functions server', (value) => Number.parseInt(value)) | |||
.option('-s, --serve', 'run in "serve" mode', false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs a better description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about --prod
instead? We're running it in a prod-like mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I like that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ticachica any thoughts/concerns here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed to --prod
in 78c35b6.
@@ -145,11 +148,12 @@ export class FunctionsRegistry { | |||
) | |||
} | |||
|
|||
// This fixes the bug described here https://github.com/netlify/zip-it-and-ship-it/issues/637 | |||
// If the current function's file is a zip bundle, we ignore it and log a helpful message. | |||
// If the function file is a ZIP, we extract it and rewire its main file to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to do this so that the functions have all its dependencies available, otherwise we'd need to load modules from .netlify/plugins/node_modules
, which isn't part of the module resolution path. We know we've already bundled the functions as part of the build process, so we can extract their ZIP files and use the exact files that will be used in Lambda, in the spirit of simulation the production environment as closely as possible.
src/commands/dev/dev.mjs
Outdated
|
||
// When using the `serve` flag, we want to use the production functions built | ||
// by Netlify Build rather than building them from source. | ||
const dist = Boolean(options.serve) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to change the name of this variable to something more along of the lines of what the comment above is suggesting? I worry that since dist
is often used as a name for where built files are output to during a site build that this will be confusing for a future dev.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally. Done in d782283.
--serve
flag to dev
command--prod
flag to dev
command
command: undefined, | ||
useStaticServer: true, | ||
}) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log(`${NETLIFYDEVLOG} Serving production build \n${NETLIFYDEVWARN} Changed files will not be rebuilt until you restart the server`) |
Also needs changing for edge functions: https://github.com/netlify/cli/blob/feat/serve-command/src/lib/edge-functions/registry.mjs#L223 |
Co-authored-by: Matt Kane <m@mk.gg>
I'd rather do that in a follow-up PR. I don't like the idea of making the edge functions registry aware of the |
Actually, I managed to do it in a concise way in 2934233. |
docs/commands/dev.md
Outdated
@@ -30,6 +30,7 @@ netlify dev | |||
- `live` (*boolean*) - start a public live session | |||
- `offline` (*boolean*) - disables any features that require network access | |||
- `port` (*string*) - port of netlify dev | |||
- `prod` (*boolean*) - build the site for production and serve locally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just creeping on your PR 😄 How does this work with or in contrast to the context flag (documented above), that you can also set to production
?
ie netlify dev --context production
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(the CLI doc above mentions only environment variables, but our docs site makes it sound like using the context flag builds your site for production - so this would need to be updated if that's not correct)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your creeping is very much welcome and that's a great point! The CLI docs are correct: the context
flag only affects environment variables. This makes me wonder whether we should repurpose context
and introduce this new behaviour (i.e. actually building the site for production) when context
is production
. And we could make --prod
an alias for --context=production
.
I think that would make things more consistency, with just two concerns worth considering:
- That would make this a breaking change, since we'd be changing an existing flag rather than introducing a new one
- This new behaviour means that watching for files won't work, and people will have to restart the CLI for the build to be run again and their changes to be picked up. I worry that it might be confusing that a specific value of
context
triggers this behaviour, rather than an entirely new flag.
But if we decide not to reuse context
, it'll be a bit difficult to explain why you have --prod
and --context=production
.
@ascorbic What are your thoughts on this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this a bit more and I feel that a more manageable step would be to keep context
as is (i.e. just about environment variables) and make prod
automatically set --context=production
, so that you're building the production site and using the production env vars.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we have named the flag prod
, I agree that making it automatically set --context=production
feels most intuitive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is why I sugegsted having it as a separate command. Using ntl dev
when it's building for production is a little unintuitive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Building a separate command is a bigger lift (if done properly) that unfortunately I don't have the capacity for right now. I've pushed ae74853 which sets --context=production
when --prod
is set, and in f3cc600 added a "beta" label to the flag in the help menu. We do this for other commands.
I suggest that we ship this as is and then iterate on it. If we come to the conclusion that this makes more sense as a separate command, we can break it out and deprecate --prod
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that is a good compromise. Does our CLI lib support aliases? If so, that would probably be the simplest solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#5351 turns the flag into a separate command. We can get it merged after this one.
@@ -713,7 +822,6 @@ export const createDevCommand = (program) => { | |||
'--context <context>', | |||
'Specify a deploy context or branch for environment variables (contexts: "production", "deploy-preview", "branch-deploy", "dev")', | |||
normalizeContext, | |||
'dev', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By setting a default value here, we don't give commands the opportunity to set their own custom values. I've removed the default and added it in https://github.com/netlify/cli/pull/5338/files#diff-67082469659283bc342bd13f7e20570cb3d1bf5096aad88545a9ac4809d6083bR520.
*/ | ||
getDefaultContext() { | ||
const { prod } = this.opts() | ||
const isDevCommand = ['dev', 'dev:exec'].includes(this.name()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really not a fan of having command-specific logic in the base command, but by the time the command runs it's too late to change the context because the base command will have already retrieved the config. We should revisit this and build some sort of hook that commands can set.
} | ||
|
||
// Run Netlify Build using the main entry point. | ||
await buildSite(buildSiteOptions) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the build fails then it doesn't cause the server to exit. This is fine for normal dev mode, where you can fix the code and it will then recompile, but with --prod
there's no hot-reloading, so it sticks with the server running but no built site. If there's a build failure in prod it shoudl cause the server to exit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I've done it in f4f31fb to avoid merge conflicts.
Once you're happy with this PR, I can merge that one in.
// Add `NETLIFY_DEV` to the environment variables. | ||
env.NETLIFY_DEV = { sources: ['internal'], value: 'true' } | ||
|
||
// Ensure the internal functions directory exists so that any functions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will move this to a more suitable place in #5351.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
Summary
Needs netlify/build#4792. Closes #3905.