-
Notifications
You must be signed in to change notification settings - Fork 3
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
chore(common): resolve source instead of bundle on development #264
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
package.json
Outdated
"dev:js": "yarn workspace field-plugin-js-template dev", | ||
"dev:vue2": "yarn workspace field-plugin-vue2-template dev", | ||
"dev:vue3": "yarn workspace field-plugin-vue3-template dev", | ||
"dev:react": "yarn workspace field-plugin-react-template dev --config ../../dev/react-vite.config.ts", |
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.
Once this yarn workspace command is run, process.cwd()
will be packages/cli/templates/react
, not the root directory. So, the config path looks like that.
packages/cli/dev/js-vite.config.ts
Outdated
@@ -0,0 +1,15 @@ | |||
import { defineConfig } from 'vite' |
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 I said in the description of this PR, we're having this separate vite config files here, but they're actually extending the real configs, adding only this alias.
@@ -0,0 +1,15 @@ | |||
import { defineConfig } from 'vite' |
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 welcome any suggestion on this folder or filenames.
I am wondering if the extended vite config from helper functions will actually have any effect once let's say a user creates a new template and runs Quite some of the code seems to be redundant, do you think @eunjae-lee it makes sense to make the I am also playing with the idea if it was possible to create a more dynamic/simpler way of creating these dev configs, maybe by creating a special script. But the idea is not well-thought trough. I mean something like I am thinking about an easier way because every time we create a new template we need to add the new extended configuration, which might be a bit cumbersome and we will also need to add this as a new step for our contributors. |
If I get your question correctly, helper is fine. When you think about the build process, we build helpers, and copy the bundled files into
I like the idea of a script. I didn't want to overcomplicate this pull-request from the beginning. Now that you see what's going on here, and you agree on having a better way to have this config for the sake of better maintenance, I'm happy to improve this pull-request. Ping me if you have some ideas, while I work on it :) |
cc @BibiSebi |
@@ -17,4 +17,15 @@ export default defineConfig({ | |||
external: ['querystring'], | |||
}, | |||
}, | |||
resolve: { |
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.
@eunjae-lee, I may be not seeing something here, but does it make sense to have this alias also for the vite helper
?
I mean, it seems that the @storyblok/field-plugin
package is not used in this helper...Am I right?
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, nice catch! Thanks
import fs from 'fs/promises' | ||
import path from 'path' | ||
|
||
const template = process.argv[3] |
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 template = process.argv[3] | |
const template = process.argv[3] | |
const templatePath = `packages/cli/templates/${template}` | |
const newConfigPath = `${templatePath}/node_modules/.${template}-vite.config.ts` | |
await $`cp ${templatePath}/vite.config.ts ${newConfigPath}` |
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.
You can select multi-lines and suggest :)
Screenshot.2023-08-30.at.10.37.24.mp4
anyway, thanks I'll apply this.
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.
Really cool @eunjae-lee.
Thanks for sharing, it'll be helpful.
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 template = process.argv[3]
Since the template
parameter is mandatory for the script to work properly, I'm wondering if it would be nice to check if before and if it isn't provided, print a better error message.
What do you think @eunjae-lee ?
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 script is run by bump-version
, and we don't run it directly. So this script is supposed to get the argument all the time. However, I just added it for better read :)
@eunjae-lee, everything seemed nice to me. The script file was a nice idea, I tested it locally, and worked pretty well. I left one note for the sake of understanding better the SDK, but nothing which would break anything as well. |
What about merging this and creating another ticket to improve this? It does not have to be now, but in case we have the time and motivation we can look into it in the next sprint. |
Never mind, I see you already started working on it :) |
|
||
const template = process.argv[3] | ||
const templatePath = `packages/cli/templates/${template}` | ||
const newConfigPath = `${templatePath}/node_modules/.${template}-vite.config.ts` |
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.
maybe here we also need to make a small check if node_modules is present otherwise the app might crash in the next 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.
good point! but thinking of this.. if we didn't run yarn install
yet, then vite
is not there, and anyway nothing will work.
@@ -0,0 +1,29 @@ | |||
#!/usr/bin/env zx | |||
|
|||
import fs from 'fs/promises' |
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.
can we add a comment to explain the reasoning for this script? It might not be straightforward if a new dev joins us why we have this and inside the template, there is also a dev command so it might be confusing which one to use.
@@ -22,4 +22,15 @@ export default defineConfig({ | |||
}, | |||
}, | |||
}, | |||
resolve: { |
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 is totally fine for now, but the helpers will also need some kind of automated mechanism in the future, so that the developer does not need to take care of 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.
LGTM
What?
This PR updates vite configs to resolve source files instead of bundles when NODE_ENV is not
production
(probably eitherdevelopment
ortest
).It means we don't have to run build command every time we update something. More details in the comments section.
For example, vite config of Container looks like this:
It means that the source of field plugin library will be resolved instead of
@storyblok/field-plugin
inside the Container package. However, we cannot add such config to the templates, because we don't want this config inside users' created repositories, right? So I had to create separate vite configs for the templates. Couldn't find out an alternative to this approach.Why?
JIRA: EXT-1751
How to test? (optional)
Screenshot.2023-08-28.at.17.03.02.mp4