Into the future ...

[HyperBrain]

Hi, I am the new maintainer of the serverless-webpack plugin.

First of all, I'd like to thank @thenikso and the team for the great project and
the tremendous work done. Without people like him, the OSS landscape
wouldn't be what it is today.

Initially I thought, that I would not have the time to take over the project,
but after some thinking, I came to the conclusion that the project has a huge
active and lovely community, and it's not me who really maintains the project,
but it's you, the community :-)

My goal is, to lead the project to an active state again (it is really worth it)
so that with help of us all, the project receives updates frequently, and has frequent,
stable releases that integrate the fixes and features.

I know that this cannot be done within a few days, so I created a rough roadmap and
put together some topics on how to proceed to get the engines running again as fast as
possible again.

Home sweet home

As @thenisko has no time anymore to take care of the project, the project will be moved
to a new home. The ETA for this is within the next few weeks. If it turns out, that I can
manage the project time-wise, I'll transfer it to my other projects like the serverless-aws-alias
plugin. I'll know about that within the next 2 weeks - if it does not work out, I'll try to
locate another appropriate org where it can live.

Releases

I will take care of releases and define milestones for the next releases
accordingly (so that everyone knows what will make it into which next release
depending on the impact, so that it stays SemVer compliant).

Versioning

The next released version will start with 2.0.0 (due to #83) and follow the SemVer pattern.
There is no reason to have versions declared as rc anymore -> there is already
a wide-spread use of the project.
This also makes it clear for every user if, and when, to switch to a new version without
the risk to break everything.

Milestones

I will create GitHub milestones for the upcoming releases (especially 2.0.0 now). Every PR or
task that we (the community) analyzed will be assigned to the milestones, as soon as it is clear
that it will be part of one of the next releases.

Next release

I'd like to release a new version as soon as possible. The release should only contain the stable
and verified fixes that are already available (see Open PRs). This is very important, as the project
is used in production environments and as no semver is in place until now, will eventually break
deployments if we include some risky stuff in the 2.0.0 release.

Open PRs

Currently there are 27 pull requests open. Some of them are already tested, some of them do
not solve the addressed problems completely, and some of them do not relate to any open issue.

For the very next release (that should be done asap) it is important that the open PRs are
analyzed as a very first step, so that all PRs that are viable (decision by the community) can be merged.

We all should work through the list of PRs and check if they are:

• finished from an implementation perspective
• solve the given problem as intended
• are reviewed
• are tested for side-effects and functionality

If you checked these points, please leave a comment in the PR, so that we can define the status
of the PR together, and decide if it will be part of the next immediate release. If so, I will
add the PR to the 2.0.0 milestone, so that we get an overview about what will and can be included.

Current master

Currently there is one merge in master #83 which is not yet released. It is the arbitrary webpack version support which is already used by many people. Naturally this will be part of the release.

Tags

I will add tags to each PR we discussed. PRs that are not viable for the 2.0.0 release will be
tagged accordingly and we should discuss them further and work on them to get them finished.

Open issues

There is also a bunch of open issues. The first priority is to address the open PRs to get
2.0.0 out asap. But there are still a lot of issues open, that do not have any reaction since
a long time.

The 2.0.0 should not contain fixes that are not yet available as PR! It is meant to release
a fresh updated version within the next week. For the release following 2.0.0 (may it be 2.0.1
or 2.1.0 depending on the contained fixes) we have time to add solutions for existing but not already
solved issues.

We have to walk over the issues and try to check if the issues are valid issues, or if any information
is missing there. I will add tags to them accordingly, so that we see what needs to be done there or
delete them, if a discussion within the issue shows that it is not really a problem.

Code quality / Coverage

I will setup some mechanisms to make sure that quality issues or failing unit tests are catched
as early as possible. These should be setup within the next few weeks.

PR description template

The Serverless core framework implemente nice and useful templates for new issues and PRs. I will
integrate them into the project, as they are very helpful to make sure that issues have all needed
information to rate/analyze them from the beginning. For PRs they help to tell the status and remind
people of parts that are likely to be missed like documentation or unit tests.

Coveralls

Coveralls provides a very nice unit test code coverage tracking and warns you if any implementation
decreases the coverage (i.e. adds untested code). Istanbul, which is used by the Serverless core
framework (and my alias plugin) already uses the service.

Travis

I will integrate Travis, so that for every commit and PR, the unit tests are run and any contributor
immediately gets a helpful feedback.

ESLint

I will also integrate ESLint into the project to make sure that no avoidable issues exist before merging pull requests. Every PR will trigger a Travis build and lets run ESLint over the code. If there are issues the build will fail and there will be a notification in the PR that shows that something has to be fixed.

Community / Volunteers

The further success of the project is heavily dependent on the community (YOU ❤️ ). So please volunteer
to help getting it on the right path again. I will add frequent volunteers as contributors to
the project, so that we can continue with a normal project life after we have brought it back
to life initially.

This should make it possible to build up a core maintainance team, that makes sure that the project
will never become inactive again.

Until then, I will manage and perform the npm releases - with the fixes and features included, that
we, the community decided to be in.

References

I attached a link to each PR here to make sure that everyone who submitted or
worked on a solution of a problem gets notified about the reactivation of the project.

#132, #131, #130, #129, #127, #112, #110, #106, #105, #104, #103, #101,
#97, #96, #93, #92, #91, #90, #88, #85, #82, #81, #80, #74, #45, #30, #18

I'd love to hear your thoughts about all this.

Cheers
Frank

[HyperBrain]

Oh, forgot to reference the issues to notify anyone who created an issue that is still open.

#128 , #126 , #125 , #124 , #123 , #121 , #120 , #118 , #117 , #116 , #115 , #113 , #108 , #107 , #100 , #99 , #98 , #95 , #89 , #86 , #84 , #76 , #71 , #70 , #68 , #66 , #64 , #62 , #60 , #54 , #46 , #44 , #42 , #38 , #11 , #133

[hassankhan]

Possibly add Commitizen for commit-checking and changelog generating?

Also not sure if this is the right place, but is it time to retire the serve functionality since it's better covered by both serverless-offline and serverless-simulate?

[HyperBrain]

Yeah. Good points. Can you open an issue as base for the discussion about the serve functionality? It would be good if we had some feedback that represents the real-life use cases and know why people use it or do not use it, or how the us cases are there in combination with other plugins. I'll add the question/help-wanted tags then.

[hassankhan]

Done and done.

EDIT: @HyperBrain: Is moving the repo to the Serverless Community Labs group an option? Seems like it would be a good fit, would love to know your thoughts.

[HyperBrain]

@hassankhan I'm not really sure.

This organization has no public members. You must be a member to see who’s a part of this organization.

A possible target group imo must be public and must not be owned by any commercial organization to protect the project.

Nevertheless I'd like to postpone the organization discussion and decision until we got the project rolling again, i.e. version 1.0.0 has been released, the open PRs are rated and checked and the issues have been analyzed. Moving it and getting it running again in parallel might lead to distractions. I see employing measures to get it to a normal development and release state as the most urgent tasks right now.
Moving to another organization would also mean to have a dummy release at that point of time right away as all links have to be updated which would interfere with bringing the project back on track asap.

[hassankhan]

@HyperBrain I'm happy to reach out to them if you'd like, I'm sure those issues could be resolved. However, as you say, there are more pressing matters 😄

[HyperBrain]

I will tag all PRs that are candidates for the 1.0.0 release with the pr/candidate label. This should include PRs that are finished and already tested. We should then inspect these again, so that they are reviewed by at least two people (who should approve the PR with their review) and ideally tested again. If everyone agrees, I will merge them afterwards.
Please let me know of which you also think they are candidates that impose low risk.

[hassankhan]

I've had a look through and sorted the PRs somewhat (happy to split some of these off into their own issues for checklists if you'd like):

Documentation fixes

#142 (merged)
#140 (merged)
#132 (merged)
#104
#88 (merged)

Serve functionality

#112
#106
#93
#92
#85
#82
#45

Should be in v2

#131 (merged)
#130
#129
#127 (merged)
#96

Possibly outdated/superseded

#105 (superseded by #131)
#103
#97 (superseded by #83)
#91 (superseded by #130)

Should be in the next release

#18

Unclear description/purpose or possible WONTFIX

#101
#90
#30

[HyperBrain]

@hassankhan Thanks for the list 👍 . I moved #91 to superseded too (by #130). Some of the serve PRs are already closed.

[HyperBrain]

I disagree with #90 . This will disable the whole optimization of webpack and just include everything, even if it is not needed anymore after tree-shaking and module optimization. I will comment in the PR.

In general people should open an issue for problems first, where more people can discuss it and suggest a solution, instead of just submitting a PR for something that isn't discussed before. There are some PRs that are completely unrelated to any issue (e.g. the TypeScript PR should have an associated issue too, because discussing possible solutions within a PR is not helpful as it can obsolete the presented solution completely), change existing functionality or are even breaking.

We should give people a hint in PRs of that kind that they should open and link an issue to the PR.

[hassankhan]

Agreed @HyperBrain, just wasn't sure if there was more to the issue than that.

As for the issue/PR problem, I see you've already added Issue/PR templates 👍 . Going forwards, we should definitely aim to have discussions in issues before PRs though.

[hassankhan]

I've moved #90 to Unclear/WONTFIX and updated a few of the links

[HyperBrain]

@hassankhan I used the Serverless templates as base, as I thought they are a good start, but extended them (for the issue template) to also contain the webpack and the plugin version.
I rethought the 1.0.0 again, and came to the conclusion that as #83 is breaking (users have to add webpack themselves to the project), we should release the next version as 2.0.0 and add a note about the peer dependency to the README. This will let old projects still build, but everyone currently using master or a fork can seamlessly switch to 2.0.0. I updated the issue description accordingly.

#138 Is the task for that. If you have time you could add a PR that we can merge 😄

[hassankhan]

Yep you're right, if we're trying to follow SemVer it is indeed a breaking change. However, since it was still technically a pre-release, I'm not sure what the rules are there. Either way, it's just a number 😄

[hassankhan]

Might be worth having a Gitter room, don't think it's terribly urgent but would be nice to have in the future.

[hassankhan]

Might also be nice to add Codacy support, it's pretty darn handy for detecting potential code issues and hot paths (and free for open-source!).

[HyperBrain]

@hassankhan Everything selected for 2.0.0 has been addressed (with exception of #104, which has to be reviewed or decided now). The next immediate features are already assigned to 2.1.0 (especially #130 and #129).

I'd like to release the 2.0.0 tomorrow if we're good to go 😃 . Depending the progress of the 2.1.0 issues there might be a next release by end of next week - then we should also have the first feedback for 2.0.0.

I created a 3.0.0 milestone for the breaking changes we might have planned (e.g. drop of the serve command). This is completely unrelated from any 2.x.x release that might come before.

[hassankhan]

[HyperBrain]

Version 2.0.0 is now available on npmjs

[hassankhan]

Been waiting for a while to do this 😄 :

[joncursi]

Is webpack tree-shaking on the horizon? One of the packages I require has a huge dependency graph, but I just need a handful of things from it. I'm almost at the 50 MB bundle size limit 😨

[HyperBrain]

@joncursi Isn't tree shaking a feature of Webpack that can be configured through your webpack configuration? It will only be enabled if you configure Webpack for production builds: See https://webpack.js.org/guides/tree-shaking/ and https://webpack.js.org/guides/production/

So, if you configure your webpack to use it, it will work. Of course you should switch to WebPack 2 or WebPack 3 first.

[joncursi]

@HyperBrain I am using serverless deploy to push code to AWS for me rather than building the webpack bundle manually and uploading myself. If I want to create a "production" build using serverless deploy, are there special flags I need to pass on the CLI? Or are there options I can drop in serverless.yml?

Or is the only option to create the bundle manually with webpack and then find another way to upload it?

[HyperBrain]

It should all work with serverless deploy. Configuring the uglify plugin and other Webpack plugins is done only in your webpack.configuration. As you can set the used webpack configuration in the serverless.yml you can make the used webpack.conf dependent on ${opt:stage, opt:provider.stage} as variable. So you could load a webpack.dev.conf.js for dev and a webpack.prod.conf.js for prod.

The prod configuration would enable all plugins as shown under "the manual way" in the webpack production documentation.

A serverless deploy will then use the configuration depending on the stage that you select.

[HyperBrain]

Closing this - we reached most of the goals right now (see #213 )