-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Built in integration of serverless enterprise #6074
Conversation
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.
Looks good so far @dschep 👍
Just added one comment regarding path joining...
.travis.yml
Outdated
- node_js: '4.4' | ||
env: SLS_IGNORE_WARNING=* | ||
- node_js: '5.11' | ||
env: SLS_IGNORE_WARNING=* |
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 would leave it to #6077 (still I guess it was probably done to have CI pass)
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.
Yes, either that has to be merged first or I have to do it here too.
.travis.yml
Outdated
@@ -42,6 +38,7 @@ matrix: | |||
- LINTING=true | |||
sudo: false | |||
install: | |||
- travis_retry npm install -g npm |
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.
Why? (line below it's followed by npm install
)
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.
npm install doesn't upgrade npm and some dep of enterprise plugin requires a new version of npm to install correctly.
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.
Isn't that related purely to npm version that comes with Node.js v4? (of which testing we drop)
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'll try removing it but i think other versions needed update dnpm too
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 think once testing of v4 and v5 is dropped, it should not be an issue (and better to drop it, as it adds time to CI build, and installs npm version not yet "approved" by Node.js)
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 already drops node 4&5, it's still needed on node 6
@@ -148,7 +152,27 @@ class PluginManager { | |||
if (pluginsObject.localPath) { | |||
module.paths.unshift(pluginsObject.localPath); | |||
} | |||
this.loadPlugins(pluginsObject.modules); | |||
this.loadPlugins(pluginsObject.modules | |||
.filter(name => name !== '@serverless/enterprise-plugin')); |
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 just to prevent accidental load of enterprise plugin if user lists @serverless/enterprise-plugin
in serverless.yml
plugins section?
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.
yes.
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 because we don't want to load plugins twice? In that case we already have (or had) that logic in the plugin manager.
Maybe the logic related to the @serverless/enterprise-plugin
is an edge case though...
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.
It's probably good to treat it separately here, but I guess it'll be good to show some warning to the user, that @serverless/enterprise-plugin
should not be listed as plugin (and carry on as normal).
That way we don't leave an impression that such configuration of a plugin is expected.
@pmuens i can't seem to reply directly. but yes, we don't want to throw a warning about the duplicate either. |
@medikoo it is intentional to load after other plugins. This is because it has to be after plugins like webpack or other transpilation tools. |
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.
It needs conflicts to be resolved
.travis.yml
Outdated
@@ -36,6 +36,7 @@ matrix: | |||
env: SLS_IGNORE_WARNING=* | |||
sudo: false | |||
install: | |||
- "[ $TRAVIS_OS_NAME = windows ] || travis_retry npm install -g npm" |
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.
Why is it needed just in Windows case?
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.
npm i -g npm doesn't work on windows travis builders bc apparently the user doesn't have enough permission, and it's not necessary bc the windows build has a new enough node/npm that it doesn't need to be upgraded.
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.
As we clarified on Slack, it's about invalid listing of zlib
in package.json. it's old module that doesn't compile on new node.js versions (recent ones totally ignore it), and crashes v6.
zlib
is a Node.js native module since v0.12.
Removing it from package.json
will fix it
@@ -148,7 +152,27 @@ class PluginManager { | |||
if (pluginsObject.localPath) { | |||
module.paths.unshift(pluginsObject.localPath); | |||
} | |||
this.loadPlugins(pluginsObject.modules); | |||
this.loadPlugins(pluginsObject.modules | |||
.filter(name => name !== '@serverless/enterprise-plugin')); |
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.
It's probably good to treat it separately here, but I guess it'll be good to show some warning to the user, that @serverless/enterprise-plugin
should not be listed as plugin (and carry on as normal).
That way we don't leave an impression that such configuration of a plugin is expected.
@@ -1,5 +1,7 @@ | |||
service: | |||
name: aws-alexa-typescript | |||
#app: your-app-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.
I guess it's about credentials to Enterprise account. Wouldn't it be better to accompany it with comment as e.g.:
# A credentials to eventual Serverless Enterprise account
# see https://serverless.com/acceleration/ for more details
Otherwise it gives no hint what those settings are about
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.
it's not a credential, but yeah, i'll check with product what copy they'd like
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.
Pretty sure it is, but is this only required for our AWS templates right now?
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.
Correct. SFE only supports AWS.
…alls with old versions of npm
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.
LGTM from a code perspective
Just added 2 minor questions.
if (config.getGlobalConfig().enterpriseDisabled) { | ||
return; | ||
} | ||
module.paths.unshift(path.join(__dirname, '../../node_modules')); |
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 might've asked this before, but this will work on Windows, since path.join
is able to turn /
into \
, 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.
oh right.. i tested this when i did it the other way (hacking it into a relative import). I think this'll work, but I'll boot up my window sbox to double check
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.
works!
@@ -1,5 +1,7 @@ | |||
service: | |||
name: aws-alexa-typescript | |||
#app: your-app-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.
Pretty sure it is, but is this only required for our AWS templates right now?
What did you implement:
PLAT-916
How did you implement it:
Added SFE plugin as a dependency and automatically load it, explicitly from sls's
node_modules
to avoid issues with global installation.How can we verify it:
if you have logged into SFE, first remove those details from or remove the
~/.serverlessrc
file entirely. Then use sls to do some deploys, you should get the ad about SFE on deploys.then run
sls login
and deploy again, you should get warnings about configuring app&tenant.configure app&tenant and deploy again. should now be using SFE!
Todos:
Is this ready for review?: YES
Is it a breaking change?: NO