Skip to content
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

Merged
merged 8 commits into from
Sep 4, 2023

Conversation

eunjae-lee
Copy link
Contributor

@eunjae-lee eunjae-lee commented Aug 28, 2023

What?

This PR updates vite configs to resolve source files instead of bundles when NODE_ENV is not production (probably either development or test).

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:

  resolve: {
    alias:
      process.env.NODE_ENV === 'production'
        ? []
        : [
          {
            find: /^@storyblok\/field-plugin$/,
            replacement: path.resolve(
              __dirname,
              '../field-plugin/src/index.ts',
            ),
          },
        ],
  },

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

@vercel
Copy link

vercel bot commented Aug 28, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
plugin-sandbox ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 4, 2023 8:26am

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",
Copy link
Contributor Author

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.

@@ -0,0 +1,15 @@
import { defineConfig } from 'vite'
Copy link
Contributor Author

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'
Copy link
Contributor Author

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.

@eunjae-lee eunjae-lee marked this pull request as ready for review August 28, 2023 16:01
@BibiSebi
Copy link
Contributor

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 yarn dev.

Quite some of the code seems to be redundant, do you think @eunjae-lee it makes sense to make the alias a reusable constant?

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 yarn dev-internal:react and the script would generate the correct temporary configs.

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.

@eunjae-lee
Copy link
Contributor Author

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 yarn dev.

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 packages/field-plugin/dist/... At that point, helpers' vite config doesn't matter. Let me know if it's still unclear!

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 yarn dev-internal:react and the script would generate the correct temporary configs.

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 :)

@eunjae-lee
Copy link
Contributor Author

cc @BibiSebi
(forgot to ping you)

@@ -17,4 +17,15 @@ export default defineConfig({
external: ['querystring'],
},
},
resolve: {
Copy link
Contributor

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?

Copy link
Contributor Author

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]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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}`

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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 ?

Copy link
Contributor Author

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 :)

f7726dc

@demetriusfeijoo
Copy link
Contributor

@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.

@BibiSebi
Copy link
Contributor

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 yarn dev.

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 packages/field-plugin/dist/... At that point, helpers' vite config doesn't matter. Let me know if it's still unclear!

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 yarn dev-internal:react and the script would generate the correct temporary configs.

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 :)

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.
As long as it works, I think we can merge it like this, but, we need to include the information inside about the steps inside the README for contributors.
What do you think. @eunjae-lee.

@BibiSebi
Copy link
Contributor

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`
Copy link
Contributor

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?

Copy link
Contributor Author

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'
Copy link
Contributor

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: {
Copy link
Contributor

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.

Copy link
Contributor

@demetriusfeijoo demetriusfeijoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@eunjae-lee eunjae-lee enabled auto-merge (squash) September 4, 2023 08:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants