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

feat(common): pass manifest json to sandbox #273

Merged
merged 17 commits into from
Sep 22, 2023

Conversation

demetriusfeijoo
Copy link
Contributor

@demetriusfeijoo demetriusfeijoo commented Sep 18, 2023

What?

It allows the Sandbox/Container to bootstrap options from a manifest file located within a field-plugin root folder.

Why?

JIRA: EXT-1877

see the RFC

When our Vite printDev plugin finds the manifest file:
Screenshot 2023-09-18 at 08 49 36

When our Vite printDev plugin doesn't find the manifest file:
Screenshot 2023-09-18 at 08 52 17

When our Vite printDev plugin finds the manifest file but it's not valid:
Screenshot 2023-09-18 at 08 58 45

How to test? (optional)

From the root folder of this repository, run:

  1. yarn dev:container
  2. yarn dev:react
  3. Open Sandbox

It should load the options automatically (from the manifest file) like below:
image

If you want to change the manifest options locally, edit this file here React Manifest

@vercel
Copy link

vercel bot commented Sep 18, 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 22, 2023 10:15am

@eunjae-lee eunjae-lee changed the title feat(common): Pass manifest json to sandbox feat(common): pass manifest json to sandbox Sep 18, 2023
@demetriusfeijoo demetriusfeijoo marked this pull request as ready for review September 18, 2023 12:54
@@ -0,0 +1,12 @@
const styles = {
reset: '\u001b[0m',
Copy link
Contributor

Choose a reason for hiding this comment

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

There is also a library for having colorful outputs in your console logs. I believe it is this one (https://www.npmjs.com/package/chalk) we are also using in the CLI

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'll check it out @BibiSebi. I saw the CLI uses it but have never tried it on my own. 🤔

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah tbh I'd prefer using the library instead of keeping the color codes here. And it's not increasing our bundle size either (only for development mode).

But if you add chalk, you should add it to the vite config's externals as well. (Let me know if you don't understand what that is for)

@BibiSebi
Copy link
Contributor

Side note: just randomly found this library that is even used by prettier https://github.com/cosmiconfig/cosmiconfig that helps loading configurations. Maybe we can check it out


export const load = (): Manifest => {
try {
const content: string = readFileSync(MANIFEST_FULL_PATH, {
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 can do some kind of validation ? to check if the schema is ok ? it might be that the user types in something weird. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It would be nice Bibi. You mean using some library such as joi, right?

It'd be a great improvement o/

Thanks for the suggestion @BibiSebi. 🚀

@eunjae-lee
Copy link
Contributor

Side note: just randomly found this library that is even used by prettier https://github.com/cosmiconfig/cosmiconfig that helps loading configurations. Maybe we can check it out

Interesting. It's similar to https://github.com/unjs/c12

I guess those packages are specifically useful when we want to support different types of configs (e.g. an object within package.json, something.json, something.js, something.ts, ...)

@demetriusfeijoo
Copy link
Contributor Author

Side note: just randomly found this library that is even used by prettier https://github.com/cosmiconfig/cosmiconfig that helps loading configurations. Maybe we can check it out

Thanks for sharing @BibiSebi.
I'm going to read about it and make some tests here. 🙌

@@ -0,0 +1,12 @@
{
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this will lead to users having unexpected options (option1, option2) by default (probably without knowing it).

What if we have an empty array for options in the templates?

Copy link
Contributor Author

@demetriusfeijoo demetriusfeijoo Sep 18, 2023

Choose a reason for hiding this comment

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

Makes sense @eunjae-lee.

It should be enough once we work on the documentation.

Copy link
Contributor

Choose a reason for hiding this comment

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

Then could you remove these options from this branch? I know it might be annoying for you to test with actual values, but they shouldn't be committed here any more.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done @eunjae-lee.

packages/cli/templates/js/field-plugin.config.json Outdated Show resolved Hide resolved
export const load = (): Manifest => {
try {
const content: string = readFileSync(MANIFEST_FULL_PATH, {
encoding: 'utf-8',
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can drop this as it's by default.

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 mean without making use of other libraries such as cosmiconfig, right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh I meant "utf-8" here

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've tried without informing the encoding as suggested, @eunjae-lee, but when it's not informed, the readFileSync returns a buffer instead of a string. As I'd need to convert it into a string in order to call JSON.parse, I think the easiest way would be to keep the encoding part but in its shortcut way:

const content: string = readFileSync(MANIFEST_FULL_PATH, 'utf-8')

I'll commit this way and if you may have another option, let me know, please.

packages/field-plugin/helpers/vite/src/sandbox.ts Outdated Show resolved Hide resolved
packages/field-plugin/helpers/vite/src/sandbox.ts Outdated Show resolved Hide resolved
packages/field-plugin/helpers/vite/src/sandbox.ts Outdated Show resolved Hide resolved
@@ -0,0 +1,12 @@
const styles = {
reset: '\u001b[0m',
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah tbh I'd prefer using the library instead of keeping the color codes here. And it's not increasing our bundle size either (only for development mode).

But if you add chalk, you should add it to the vite config's externals as well. (Let me know if you don't understand what that is for)

@eunjae-lee
Copy link
Contributor

ping me here when you're ready for another review :)

demetriusfeijoo and others added 2 commits September 21, 2023 14:02
Co-authored-by: Eunjae Lee <hey@eunjae.dev>
…toryblok/field-plugin into EXT-1877-pass-manifest-json-to-sandbox
@@ -0,0 +1,12 @@
{
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done @eunjae-lee.

}
}

const validateSchema = (manifest: Manifest): void => {
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've added this simple validation, without using any external packages, here since we decided not to go too far on this.


export const load = (): Manifest => {
try {
const content: string = readFileSync(MANIFEST_FULL_PATH, 'utf8')
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here I kept informing the encoding since otherwise it would return me a Buffer instead of a string.

So, this way is the simplest one, I guess. If there is any other better way, let me know, please.

Copy link
Contributor

Choose a reason for hiding this comment

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

We've had some other code like readFileSync(...).toString(). I don't know what's better, though.


const chalk = new Chalk({ level: 1 })

export const green = (text: string) => chalk.green(text)
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've decided to keep this file here, even after using the Chalk package, as it serves as an abstract layer and allows us to easily switch between libraries in the future (e.g. kleur). Such as it was done now. I've just needed to change it here and for the rest of the helper was transparent.

@demetriusfeijoo
Copy link
Contributor Author

It's ready for another review round @eunjae-lee. 🙌

throw new Error(`When declared, the 'options' property should be an array`)
}

manifest.options?.forEach((o) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

let's rename this o to option to be more informative. Other than that, it looks good!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the suggestion here, @eunjae-lee. 🙌

I've just renamed it.

If there is something else, let me know, please.

Copy link
Contributor

@eunjae-lee eunjae-lee left a comment

Choose a reason for hiding this comment

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

Looks good to me @demetriusfeijoo !

Could you also create another PR to add some tests? I should've noticed it earlier but now I think we could add some tests for some functions in manifest.ts and sandbox.ts. However I don't want to delay the merge of this PR. So let's do it separately :)

@demetriusfeijoo
Copy link
Contributor Author

Thanks for the effort in reviewing it @eunjae-lee.

I've created a task for adding the tests, thanks for pointing it out. 🙌

@demetriusfeijoo demetriusfeijoo merged commit d9bdb1b into main Sep 22, 2023
11 checks passed
@demetriusfeijoo demetriusfeijoo deleted the EXT-1877-pass-manifest-json-to-sandbox branch September 22, 2023 13:15
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