-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Move @elastic/datemath into monorepo #16531
Conversation
This is a package, not a plugin, right? |
🙈 Yep. Still a WIP, I'm just exploring the flow when using a package like this across Kibana and x-pack (or any other plugin). |
adc06f5
to
4baff7e
Compare
💚 Build Succeeded |
Okey, this is ready to review |
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.
Code LGTM, just a couple of minor nits/questions + please add trailing new lines to all new files. Going to run Kibana and find the places where this package is used, so keeping r? for now
packages/kbn-build/README.md
Outdated
@@ -117,6 +117,9 @@ For more details, run: | |||
yarn kbn | |||
``` | |||
|
|||
Bootstrapping also calls the `kbn:boostrap` script for every included project. | |||
This is intended for packages that needs to be built/transpiled to be usable. |
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.
typo: that needs
---> that need
?
|
||
/** | ||
* At the end of the bootstrapping process we call all `kbn:bootstrap` scripts | ||
* in the list of projects. We do this because some projects needs to be |
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.
typo: needs
--> need
.
packages/kbn-datemath/.gitignore
Outdated
lib | ||
node_modules | ||
npm-debug.log | ||
yarn.lock |
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.
question: don't we want to commit yarn.lock
? Also do we need .gitignore
in the package itself?
Same question for .npmignore
, why do we need this? We have private: true
in the package.json
so it doesn't seem like we want to ever publish this package.
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, yarn.lock can stay now that we aren't installing from npm, and the rest of the stuff in this file is redundant, so I removed the file
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.
Also the .npmignore file
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.
++ good catch
export async function prepareProjectDependencies(settings, logger) { | ||
await handleLinkDependencies( | ||
settings.workingPath, | ||
logger |
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.
nit: looks like you don't use logger
in handleLinkDependencies
.
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.
✅
const depVersion = deps[depName]; | ||
|
||
if (depVersion.startsWith(LINK_DEP)) { | ||
if (isKibanaDep) { |
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.
issue: it's always true
since you don't call isKibanaDep
function at all (looks like it needs a simple test) :)
Also is there any reason why we don't want to just use if (depVersion.startsWith(LINK_DEP) && !isKibanaDep(depVersion)
without nested empty if
? We can easily expand it once we need it.
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.
Haha 🙈 I've added some tests for it. And fixed the if
too (initially did it like that because I had code in the "kibana-if" too, but yeah, this is cleaner)
💚 Build Succeeded |
Btw, here's a tiny Kibana plugin I created using the plugin-helpers changes (elastic/kibana-plugin-helpers#57) that relies on First build Kibana (
and you should see something like this in the output when starting the Kibana server:
(you'll see it during optimize after plugin install, as optimize starts the kibana server) EDIT: updated zip, should now log at startup on server, when the api endpoint is hit, and when opening the plugin in the ui. |
Ah, nice! I was about to ask you how to test |
💚 Build Succeeded |
💚 Build Succeeded |
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.
Haven't noticed any issues while running Kibana and installing of the example plugin, LGTM
// e.g. imports resolve properly. If we don't build the packages here, the | ||
// `main` field in their `package.json` would link to a location that | ||
// doesn't exist yet. | ||
'buildPackages', |
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 no longer needed because of the change to kbn bootstrap
(it runs kbn:bootstrap
scripts defined in package.json
in all packages)
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
💚 Build Succeeded |
284ffe9
to
368664b
Compare
💚 Build Succeeded |
f9ced51
to
3a92092
Compare
💚 Build Succeeded |
packages/kbn-datemath/.babelrc
Outdated
{ | ||
"presets": [["env", { | ||
"targets": { | ||
"node": "6.0", |
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 should use node: current
rather than pinning to node 6
packages/kbn-datemath/package.json
Outdated
}, | ||
"devDependencies": { | ||
"babel-cli": "^6.26.0", | ||
"babel-core": "^6.26.0", |
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.
babel-core isn't necessary
💚 Build Succeeded |
@@ -0,0 +1,20 @@ | |||
{ | |||
"name": "@kbn/datemath", | |||
"version": "5.0.0", |
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 shouldn't need to version this. We should only even need to include a license if it's forked from a separate project (which this particular package is).
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.
Haha, I'm sooo used to npm complaining that I've added because of that. But yarn isn't complaining about missing version, so I'll 🔥 it
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 wouldn't complain either because this package is marked as private, which disables pretty much all of the npm integrity checks.
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.
Aaand it's a no-go:
18:35:14 Installing dependencies in [kibana]:
18:35:14
18:35:15 $ node ./preinstall_check
18:35:15 [1/5] Validating package.json...
18:35:15 [2/5] Resolving packages...
18:35:15 error Package "@kbn/datemath@" doesn't have a "version".
18:35:15 info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
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.
What? Why on earth would it do that? Maintaining versions on these packages doesn't make any sense, and it's definitely going to get out of date really fast. I'd argue it's out of date the moment it is contributed to the project :P
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? I expect because link:
and private: true
are edge-cases.
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 curious, and this seems like a decent place to ask; why not just pin all the package versions to the Kibana version in the root, ala lerna's default behavior (ie. not independent mode)? They're all technically new packages, so it's not like we'd be rolling back versions or anything. And they're all pretty hard-bound to Kibana anyway... and we're also not publishing any of them.
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've been thinking about the same thing. We could write some tooling in yarn kbn
to handle it. It could require exact version match on all private: true
packages, for example. That way we could still have publishable packages, if we want to (not sure we do want that any more, though, so it might not be necessary at all and we just require exact same version on every package)
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's what I was thinking too. A kbn version
, similar to npm version
(or I assume lerna, I've only used lerna with independent versioning so far) that would just pump core and all the packages with it.
💔 Build Failed |
This reverts commit 8924a0b.
💚 Build Succeeded |
💚 Build Succeeded |
💚 Build Succeeded |
💚 Build Succeeded |
This pulls in
@elastic/datemath
to the monorepo, renames it to@kbn/datemath
, and cleans up a couple things.This will require
yarn kbn bootstrap
instead of justyarn
, as you'll otherwise see errors like:or
as the
@kbn/datemath
package needs to be built before it can be used.NOTE: This does not work with Kibana plugins until #16509 and elastic/kibana-plugin-helpers#57 are merged.
https://github.com/elastic/x-pack-kibana/pull/4505 is using it in x-pack.