Features from netlify-local

[8eecf0d2]

As per email discussions...

I'm the maintainer of 8eecf0d2/netlify-local and would like to discuss some ideas for merging features from there and into here.

The goal of netlify-local is to emulate all appropriate Netlify features for the purpose of local development (some features such as Identity might not make sense to emulate locally), whereas netlify-lambda appears to focus on the Netlify Functions feature specifically.

From what I can tell, there are no major differences between netlify-lambda and netlify-local in terms of emulating Netlify Functions and the implementations are functionally the same.

Because of this there aren't many meaningful features within the scope of netlify-lambda that could be brought over from netlify-local, so for any features to be merged I'd suggest that netlify-lambda's scope should be increased (so that features can be merged) or potentially netlify-local could be transferred across to Netlify in it's entirety.

If a scope increase or ownership transfer sounds reasonable, I think the following issues should be figured out before hand.

• Explore the idea proposed in Custom Netlify configuration properties 8eecf0d2/netlify-local#12 where the configuration options can be defined within netlify.toml under a plugins property (storing configuration options in command line arguments is a pain imo).
• Finish (correctly) implementing the Redirect / Static Server features from Correctly implement Redirect feature 8eecf0d2/netlify-local#8.
• Better document the supported features of the package (Static Server, Redirect, Headers, Lambdas) and how to use them.
• Expose an API for running the package programatically (mostly implemented in netlify-local).
• Improve the built-in bundling features to:
  • Only do the bare minimum required for bundling.
  • Support custom Webpack configurations (without merging).
  • Allow more declarative configuration for bundling (eg, plugin.local.functions).
  • Expose an API to the same effect of 8eecf0d2/webpack-netlify-lambda-plugin.

Thanks for reading, look forward to your thoughts 😊

[swyxio]

originally i was gung-ho for growing netlify-lambda but then i realized the name kinda conveys what it was meant to do.

in the spirit of unix "do one thing well" philosophy i think i'm in favor of either transferring netlify-local or just keeping it under your name but more strongly recommending it in our docs and stuff. as opposed to growing the scope of netlify-lambda unless we really have to. if people end up just using netlify-local everywhere I'd also be fine deprecating netlify-lambda. (i think we should be able to dig up usage stats from our logs after a few months).

benefit of transferring is that it seems "more official". Benefit of not transferring is you have more ownership. Either way I am keen on working with you to support these features if we ever break them. Which do you prefer to do?

---

re specific items:

configuration options can be defined within netlify.toml under a plugins property

might want to give it a different name, like netlify-local.toml. or dont even use toml if you like :) but anyway we want to enforce a clear separation between what is part of the emulation and what is part of the netlify platform.

Improve the built-in bundling features: Only do the bare minimum required for bundling.

what is the argument for this exactly? is it a speed thing or is there something else?

Improve the built-in bundling features: Support custom Webpack configurations (without merging).

we have a -c option now... does that help?

Improve the built-in bundling features: Allow more declarative configuration for bundling (eg, plugin.local.functions).

i am also for this :)

Improve the built-in bundling features: Expose an API to the same effect of 8eecf0d2/webpack-netlify-lambda-plugin.

i honestly probably would never use this (over just using netlify-lambda) but it seems reasonable.

---

You've outlined a bunch of concerns here and i'm very grateful for that. What can we start on to get the ball rolling?

[8eecf0d2]

in the spirit of unix "do one thing well" philosophy i think i'm in favor of either transferring netlify-local or just keeping it under your name but more strongly recommending it in our docs and stuff. as opposed to growing the scope of netlify-lambda unless we really have to. if people end up just using netlify-local everywhere I'd also be fine deprecating netlify-lambda. (i think we should be able to dig up usage stats from our logs after a few months).

Agree on all of this.

benefit of transferring is that it seems "more official". Benefit of not transferring is you have more ownership.

Yeah, I thought the "official" status would be a nice to have, although read on as to why I'm potentially against transferring.

clear separation between what is part of the emulation and what is part of the netlify platform.

I agree with this, but I think the separation is made clear enough by using a plugin.xxx namespace, if modifying the netlify.toml in this way (or something similar) is not going to be supported by Netlify I'd prefer to maintain ownership and continue to do it anyway.

what is the argument for this exactly?

I'd prefer to remove babel completely and just use webpack for bundling, but since I doubt that's gonna happen, I'd prefer supporting babel-preset-env and falling back to babel-preset-xxx.
If people want to write their own config, I'd step back and just provide Netlify specific tools (8eecf0d2/webpack-netlify-lambda-plugin) or options (plugin.local.functions).

In addition to this, I'd want to add a service like Greenkeeper to ensure babel-* packages are always the latest.

we have a -c option now... does that help?

Yes indeed 😊

i honestly probably would never use this (over just using netlify-lambda) but it seems reasonable.

Yeah, only reason to include it would be to keep all the local / bundle / build stuffs in one place.

---

You've outlined a bunch of concerns here and i'm very grateful for that. What can we start on to get the ball rolling?

Having read your thoughts, I'd like to do the following:

1. Confirm that modifying netlify.toml is off the table.
   1. Transfer ownership depending on that.
2. Finish defining the plugin.local structure for netlify.toml.
3. Rewrite docs and usage for netlify-local (a bit all over the place right now).
4. Reimplement features based on new usage / docs.
5. Continue working on Netlify emulation (redirect support, identity(?), etc...)

[swyxio]

hey brod - let me confirm about the netlify.toml piece! sorry got busy in the past couple days

also: just got word from our CLI team that they're working on a compiled npm package for redirects so we may want to wait for this - since it uses the exact same go code it'd be a 1:1 emulation which is nice

[swyxio]

for what its worth i haven't forgotten about this - will try to get a specific meeting to discuss this this week.

there are also ongoing efforts to add plugins to Netlify CLI (https://github.com/netlify/cli/pull/132/files, netlify/cli#117) that will be configurable via toml in the near future (@DavidWells is working on that). we will probably want to avoid the namespace clash

[8eecf0d2]

@sw-yx how did I miss this! great news about redirects & plugins, I have continued on using the plugins namespace but happy to change in the future to support an official plugin structure.

[swyxio]

indeedy. just saw a demo internally for the local redirects. i'll be sure to let you know soon as anything is public

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[swyxio]

gonna keep this open but as per chat with Brod we have plans for future progress on these issues within the Netlify CLI rather than in netlify-lambda

[swyxio]

@8eecf0d2 alrighty - Netlify Dev is announced! (but very raw!) https://github.com/netlify/netlify-dev-plugin

So there are some things we still dont have:

• netlify identity emulation
• non-confusing netlify.toml documentation esp with the new [dev] block
• extra configuration options as you propose in netlify-local.

We have free reign to define what we want in the [dev] block and i honestly shouldve involved you much earlier in the process but i was kinda heads down building out stuff. anyway i am curious to see how it handles your needs for redirects, first and foremost.

[zigomir]

This is good to know – I was banging myself with identity running netlify dev :)

[swyxio]

@zigomir have you seen we just merged the jwt decoding for local testing of identity? netlify/netlify-dev-plugin#138