-
Notifications
You must be signed in to change notification settings - Fork 53
chore(mixed): fix imports and introduce bundler test #570
Conversation
const classNames: ClassNamesFn | ||
|
||
export default classNames | ||
} |
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 decided to use custom typings for this module.
f294915
to
363d3b4
Compare
…ore/fix-imports # Conflicts: # CHANGELOG.md
…/stardust-ui/react into chore/fix-imports # Conflicts: # CHANGELOG.md
build/gulp/scaffold/rollup.config.js
Outdated
import resolve from 'rollup-plugin-node-resolve' | ||
import commonjs from 'rollup-plugin-commonjs' | ||
|
||
const lodashExports = [ |
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.
(!) Missing exports
https://rollupjs.org/guide/en#error-name-is-not-exported-by-module-
node_modules/@stardust-ui/react/dist/es/components/Dropdown/Dropdown.js
pickBy is not exported by node_modules/lodash/lodash.js
How is this going to scale? Whenever a new function is used, do I need to remember I have to add it here?
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, it's a real problem 👎 lodash
is CJS module, so the there is only one option.
If we will use Babel and babel-plugin-lodash
this problem will gone.
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.
Resolved with external
and output.globals
, now is much cleaner
build/gulp/tasks/test-bundlers.tsx
Outdated
logger(`✔️Source and bundler's config were created`) | ||
|
||
await runIn(tmpDirectory)(`yarn rollup -c`) | ||
logger(`✔️Example project was successfully built: ${tmpDirectory}`) |
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 seems we are ignoring rollup warnings. Are we ok with it or would we like to use this as an opportunity to tighten our rules and require warning-free build in rollup? (no warnings are currently allowed in webpack build)
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 reworked it, now we have a warning whitelist, other warnings will throw.
We can fix all left circular imports in a separate PR because it will require more work.
.circleci/config.yml
Outdated
@@ -58,6 +58,9 @@ jobs: | |||
# - run: |
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.
when we are planning to return this? And, actually, what was specific reason to disable these tests - currently we have no any checks that any client is able to consume our library
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.
After #550 will be merged
build/gulp/scaffold/rollup.config.js
Outdated
@@ -0,0 +1,110 @@ | |||
import replace from 'rollup-plugin-replace' |
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 should be placed somewhere under test-projects
at the very least (we should create corresponding dir) - so that this client-oriented tests functionality will be cohesively structured
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 already placed in the separate dir. I don't want to be so specific for 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.
yes, but the same reasoning would apply well in case it will be put in any dir - thus, I am not sure that this is a valid argument.
The reasoning behind my ask is the following: currently, with the dir introduced at the place where you are suggesting, we would have the following project structure:
/build/gulp
/scaffold
/tasks
/test-projects
So, reasonable question is why scaffold
directory is placed at this level of folder hierarchy? Is its content shared by any agents/tasks? The answer is "no" - the only place where it is used is test-projects
module. Thus, I would suggest to put these bits to the module those belong to at the moment.
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 its content shared by any agents/tasks? The answer is "no" - the only place where it is used is test-projects module.
At now, yes. But in the future, I think that we will have other tasks that will should also have files and templates.
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 must agree here that better directory structure would reflect exactly what we test even. Having structure, something like:
/build/gulp
/tasks
/test-projects
/cra-ts
/parcel
...
will be much more cleaner, and it will be obvious what scenarios we got covered so far...
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.
.circleci/config.yml
Outdated
@@ -58,6 +58,9 @@ jobs: | |||
# - run: | |||
# name: Project Tests | |||
# command: yarn test:projects:cra-ts | |||
- run: | |||
name: Bundler Tests | |||
command: yarn test:bundlers:rollup |
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.
would suggest test:projects:rollup
- as this won't introduce additional entropy and will still suggest that stack that client is using for her project
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.
Moved into single entry, yarn test:projects
👍
…ore/fix-imports # Conflicts: # CHANGELOG.md
# command: yarn test:projects:cra-ts | ||
- run: | ||
name: Project Tests | ||
command: yarn test:projects |
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.
👍
|
||
task( | ||
'test:projects', | ||
series( |
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.
actually, can we run them in parallel? It seems that there is no shared state between these tasks
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 will left it as is for now. When this task will be enabled, we will able to test that it works in parallel. However, I almost sure that it will work.
This PR:
I also tested a build with Parcel manually, it works like a charm ⭐️