Wow. Nice idea ๐ . That would make the project creation really easy.
Can you create an issue in the serverless core repo and link it here, so that we can track it properly?
Then we can work and comment on a PR there - that one of us (maybe you ๐ ) initially created to get a nice template in there.
Yes @HyperBrain
I just want to focus on https://github.com/elastic-coders/serverless-webpack/pull/130 before because IMO it will have some influence here.
@franciscocpg 2.1.0 is out now! Maybe you can proceed here as soon as you have some time.
Sure @HyperBrain
I'm thinking about using examples/babel-multiple-statically-entries as our "model" (with some changes, of course) to create a new template called aws-nodejs-ecma-script (need suggestions for name) based on templates/aws-nodejs.
That's because IMO the main reason to use serverless-webpack is enabling ecma-script code style.
Oh and maybe we need to add a aws-nodejs-typescript using examples/typescript as our model?
... and #167 will remove the extension from the entry key names in lib.entries, so that [name].js has to be used as output. We should take that into account. There was a problem with typescript support ( #165 ) that will be solved there by determining the correct handler filenames. I try to release these fixes as 2.2.0 as soon as the implementations are stable.
see also the discussion in #158
So I think it's better wait for 2.2.0.
2.2.0 is out. Had to be that fast, because of the TypeScript issue with the entries export ๐ .
You can proceed here now.
I agree that there should be more than one template - the multi-static and the typescript.
We can add one that is missing later: the multi-dynamic, as soon as it is proven that the entries detection works properly now. Imo the dynamic template(s) should be the preferred ones in the future.
@HyperBrain
So how I about creating these two first templates (name / example model)
aws-nodejs-ecma-script / examples/babel-dynamically-entries
aws-nodejs-typescript / examples/typescript.
IMO these two are the ones that add more value to the serverless community that wants to use ES or typescript with serverless framework.
I would use the dynamic sample. Imo this is the preferred way now to configure the plugin/webpack in an easy and safe way. Much easier than finding out and adding new entries or removing stale ones when you add or remove functions. The manual configuration is very error-prone, especially when it comes to individual packaging and optimization in V3, which works like a charm with lib.entries.
But yes, ES and TS should be the choice for them.
Ops, I've put the wrong example.
I've edited the https://github.com/elastic-coders/serverless-webpack/issues/137#issuecomment-319768537
So those two ones?
I would prefer babel-dynamically-entries. Both samples TS and ES should use lib.entries for the entry definition.
Oh. did not refresh ๐ ... yes, right
:+1:
WIP
BTW: The lib extensions are really a great thing - did you see that I extended it with lib.serverless and lib.options in the 2.2.0 release? Now you can have stage dependent configurations with only one webpack.conf.js.
@HyperBrain
Just opened #179 to upgrade examples.
Next steps are:
I already merged #179 . It would be great if you open proper issues at SLS and link them here.
:+1:
Leave it to me
Adding aws-nodejs-ecma-script template: https://github.com/serverless/serverless/pull/4056
Adding aws-nodejs-typescript template: https://github.com/serverless/serverless/pull/4058
@HyperBrain
Both PRs are merged.
Should we close this issue right now?
Yes. We should ๐
Currently github.com does not work for me, so my reply is from mailโฆ
@HyperBrain https://github.com/hyperbrain
Both PRs are merged.
SHould we close this issue right now?
โ
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/elastic-coders/serverless-webpack/issues/137#issuecomment-323746126,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFRM3oPhpaY1ckC0W90DUrIbM8peMKadks5saYh-gaJpZM4OKtzy
.
Most helpful comment
BTW: The lib extensions are really a great thing - did you see that I extended it with
lib.serverlessandlib.optionsin the 2.2.0 release? Now you can have stage dependent configurations with only one webpack.conf.js.