diff --git a/.all-contributorsrc b/.all-contributorsrc index 8b1e947..8138af2 100644 --- a/.all-contributorsrc +++ b/.all-contributorsrc @@ -88,7 +88,8 @@ "avatar_url": "https://avatars3.githubusercontent.com/u/6643991?v=4", "profile": "https://michaeldeboey.be", "contributions": [ - "maintenance" + "maintenance", + "tool" ] } ], diff --git a/.changeset/README.md b/.changeset/README.md index 17f737f..b82bb55 100644 --- a/.changeset/README.md +++ b/.changeset/README.md @@ -1,36 +1,53 @@ # Changesets -Hello and welcome! This folder has been automatically generated by `@atlaskit/build-releases`, a build tool that works with `bolt` to help you release components from a mono-repository. You can find the full documentation for it [here](https://www.npmjs.com/package/@atlaskit/build-releases) +Hello and welcome! This folder has been automatically generated by +`@atlaskit/build-releases`, a build tool that works with `bolt` to help you +release components from a mono-repository. You can find the full documentation +for it [here](https://www.npmjs.com/package/@atlaskit/build-releases) -To help you get started though, here are some things you should know about this folder: +To help you get started though, here are some things you should know about this +folder: ## Changesets are automatically generated -Changesets are generated by the `build-releases changeset` command, though it may have been given a new name within your repository. As long as you are following a changeset release flow, you shouldn't have any problems. +Changesets are generated by the `build-releases changeset` command, though it +may have been given a new name within your repository. As long as you are +following a changeset release flow, you shouldn't have any problems. ## Each changeset is its own folder -We use hashes by default for these folder names to avoid collisions when generating them, but there's no harm that will come from renaming them. +We use hashes by default for these folder names to avoid collisions when +generating them, but there's no harm that will come from renaming them. ## Changesets are automatically removed -When `build-releases version` or equivalent command is run, all the changeset folders are removed. This is so we only ever use a changeset once. This makes this a very bad place to store any other information. +When `build-releases version` or equivalent command is run, all the changeset +folders are removed. This is so we only ever use a changeset once. This makes +this a very bad place to store any other information. ## Changesets come in two parts You should treat these parts quite differently: -- `changes.md` is a file you should feel free to edit as much as you want. It will be prepended to your changelog when you next run your version command. -- `changes.json` is a file that includes information about releases, what should be versioned by the version command. We strongly recommend against editing this directly, as you may make a new changeset that puts your bolt repository into an invalid state. +- `changes.md` is a file you should feel free to edit as much as you want. It + will be prepended to your changelog when you next run your version command. +- `changes.json` is a file that includes information about releases, what should + be versioned by the version command. We strongly recommend against editing + this directly, as you may make a new changeset that puts your bolt repository + into an invalid state. ## I want to edit the information in a `changes.json` - how do I do it safely? -The best option is to make a new changeset using the changeset command, copy over the `changes.md`, then delete the old changeset. +The best option is to make a new changeset using the changeset command, copy +over the `changes.md`, then delete the old changeset. ## Can I rename the folder for my changeset? -Absolutely! We need unique hashes to make changesets play nicely with git, but changing your folder from our hash to your own name isn't going to cause any problems. +Absolutely! We need unique hashes to make changesets play nicely with git, but +changing your folder from our hash to your own name isn't going to cause any +problems. ## Can I manually delete changesets? -You can, but you should be aware this will remove the intent to release communicated by the changeset, and should be done with caution. \ No newline at end of file +You can, but you should be aware this will remove the intent to release +communicated by the changeset, and should be done with caution. diff --git a/.changeset/config.js b/.changeset/config.js index 0cecdc5..415e70e 100644 --- a/.changeset/config.js +++ b/.changeset/config.js @@ -35,7 +35,7 @@ const getReleaseLine = async (changeset, versionType) => { .join('\n'); return `- [${versionType}] [${changeset.commit}](${getLink( - changeset.commit, + changeset.commit )}):\n${indentedSummary}`; }; @@ -54,12 +54,12 @@ const getDependencyReleaseLine = async (changesets, dependenciesUpdated) => { const changesetLinks = changesets.map( changeset => `- Updated dependencies [${changeset.commit}](${getLink( - changeset.commit, - )}):`, + changeset.commit + )}):` ); const updatedDepenenciesList = dependenciesUpdated.map( - dependency => ` - ${dependency.name}@${dependency.version}`, + dependency => ` - ${dependency.name}@${dependency.version}` ); return [...changesetLinks, ...updatedDepenenciesList].join('\n'); diff --git a/.huskyrc.js b/.huskyrc.js new file mode 100644 index 0000000..37da56c --- /dev/null +++ b/.huskyrc.js @@ -0,0 +1,5 @@ +module.exports = { + hooks: { + 'pre-commit': 'pretty-quick --staged', + }, +}; diff --git a/.prettierrc.js b/.prettierrc.js index de2f53c..f0b4ed2 100644 --- a/.prettierrc.js +++ b/.prettierrc.js @@ -1,4 +1,6 @@ module.exports = { + endOfLine: 'lf', + proseWrap: 'always', singleQuote: true, - trailingComma: 'all', + trailingComma: 'es5', }; diff --git a/.travis.yml b/.travis.yml index f24c298..fc6d5ae 100644 --- a/.travis.yml +++ b/.travis.yml @@ -8,4 +8,4 @@ script: - yarn lint cache: yarn node_js: - - "node" + - 'node' diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index dec27a2..9866a56 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -5,9 +5,9 @@ In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, sex characteristics, gender identity and expression, -level of experience, education, socio-economic status, nationality, personal -appearance, race, religion, or sexual identity and orientation. +size, disability, ethnicity, sex characteristics, gender identity and +expression, level of experience, education, socio-economic status, nationality, +personal appearance, race, religion, or sexual identity and orientation. ## Our Standards @@ -37,11 +37,11 @@ Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. -Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful. +Project maintainers have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, or to ban temporarily or permanently any +contributor for other behaviors that they deem inappropriate, threatening, +offensive, or harmful. ## Scope @@ -58,8 +58,9 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at code-of-conduct@codesandbox.io. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. +obligated to maintain confidentiality with regard to the reporter of an +incident. Further details of specific enforcement policies may be posted +separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other @@ -67,8 +68,9 @@ members of the project's leadership. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, -available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 1.4, available at +https://www.contributor-covenant.org/version/1/4/code-of-conduct.html [homepage]: https://www.contributor-covenant.org diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5772d8a..1b86e0f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,23 +2,32 @@ Thanks for considering contributing! -This project has been developed to serve use-cases that I have encountered with uploading files to codesandbox, and definitely doesn't cover all use-cases. I'd be happy though if you find something else you need for you to contribute a pull request. I'll make sure you get a review quickly. +This project has been developed to serve use-cases that I have encountered with +uploading files to codesandbox, and definitely doesn't cover all use-cases. I'd +be happy though if you find something else you need for you to contribute a pull +request. I'll make sure you get a review quickly. -If you're not confident raising a pull request, open an issue, and I can talk to you about the feature/bug fix you're looking for, and hopefully we can work out how to do it. +If you're not confident raising a pull request, open an issue, and I can talk to +you about the feature/bug fix you're looking for, and hopefully we can work out +how to do it. ## For issues -If you are reporting a bug, an attempt to understand where in our code the bug comes from, or an easy way to reproduce it is greatly appreciated! +If you are reporting a bug, an attempt to understand where in our code the bug +comes from, or an easy way to reproduce it is greatly appreciated! -If you are requesting a feature, please make sure your use-case for the feature is clearly stated, so it's easy to evaluate. +If you are requesting a feature, please make sure your use-case for the feature +is clearly stated, so it's easy to evaluate. ## Deving on this project -There are a couple of things that are probably good to know(TM) to dev on this project. +There are a couple of things that are probably good to know(TM) to dev on this +project. ### How do I get up and running? -We are using [bolt](https://github.com/boltpkg/bolt) to manage this monorepo. If you haven't worked on a bolt project, the quick get-up-and-running steps are: +We are using [bolt](https://github.com/boltpkg/bolt) to manage this monorepo. If +you haven't worked on a bolt project, the quick get-up-and-running steps are: ```sh yarn global add bolt @@ -30,17 +39,20 @@ The `bolt` command will install npm packages and link them. ### Observing changes -If you are trying to observe changes across linked packages, you will need to make sure they are built. +If you are trying to observe changes across linked packages, you will need to +make sure they are built. -`yarn build` builds all packages. -`yarn dev:csb` runs the build script for `codesandboxer` and watches it for changes. -`yarn dev:rcsb` runs the build script for `react-codesandboxer` and watches it for changes. +`yarn build` builds all packages. `yarn dev:csb` runs the build script for +`codesandboxer` and watches it for changes. `yarn dev:rcsb` runs the build +script for `react-codesandboxer` and watches it for changes. The other packages do not need to be built. ### Validating changes -Currently validation that things work is mostly being done through tests. The most important tests being the ones in `codesandboxer` and `codesandboxer-fs` which use the `/fixtures` directory to validate how they parse and load files. +Currently validation that things work is mostly being done through tests. The +most important tests being the ones in `codesandboxer` and `codesandboxer-fs` +which use the `/fixtures` directory to validate how they parse and load files. ## Adding Templates @@ -50,27 +62,44 @@ Codesandboxer currently supports: - create-react-app-typescript - vue-cli -It should be easy to add new templates. Here are the places you would need to modify: +It should be easy to add new templates. Here are the places you would need to +modify: -1. Add a template file to `packages/codesandboxer/templates/`. - A template should include a main file that imports from `example.js` (or the relevant filetype), as well as any other necessary files to run the sandbox. - 1a. Once you have your template file, export it from `packages/codesandboxer/templates/index.js` added to the object with the name of the sandbox it is for. -2. If you want a different template to be used for `codesandboxer-fs` add a template to `packages/codesandboxer-fs/templates` in the same way. (we tend to make templates for codesandboxer-fs call out the use of the sandboxer more explicitly, as it may be less clear how to debug it) +1. Add a template file to `packages/codesandboxer/templates/`. A template should + include a main file that imports from `example.js` (or the relevant + filetype), as well as any other necessary files to run the sandbox. 1a. Once + you have your template file, export it from + `packages/codesandboxer/templates/index.js` added to the object with the name + of the sandbox it is for. +2. If you want a different template to be used for `codesandboxer-fs` add a + template to `packages/codesandboxer-fs/templates` in the same way. (we tend + to make templates for codesandboxer-fs call out the use of the sandboxer more + explicitly, as it may be less clear how to debug it) ## For Pull Requests ### Code Standards -We're using flow to help keep our code neat. If you could add types to your code, that would be 😎. Code that adds tests for its use-cases is also great. +We're using flow to help keep our code neat. If you could add types to your +code, that would be 😎. Code that adds tests for its use-cases is also great. ### Documentation -If you add anything to the API, please update the documentation as well. (we also accept docs PRs if you see a way to improve our documentation) +If you add anything to the API, please update the documentation as well. (we +also accept docs PRs if you see a way to improve our documentation) ### Monitoring changes -We are using [build-releases](https://www.npmjs.com/package/@atlaskit/build-releases) to add intents to change, so we can make sure our packages are released at the right semantic version. The simple answer is run `yarn changeset` and answer the questions. If you're not certain about semantic versioning, I would recommend checking out [this documentation](https://docs.npmjs.com/about-semantic-versioning). +We are using +[build-releases](https://www.npmjs.com/package/@atlaskit/build-releases) to add +intents to change, so we can make sure our packages are released at the right +semantic version. The simple answer is run `yarn changeset` and answer the +questions. If you're not certain about semantic versioning, I would recommend +checking out +[this documentation](https://docs.npmjs.com/about-semantic-versioning). ## Please Be Nice -I'm currently working on a code of conduct, but until that's ready, I wanted to make sure that everyone felt welcome here. If you are looking to contribute, please make sure you are respectful to anyone participating on this project. \ No newline at end of file +I'm currently working on a code of conduct, but until that's ready, I wanted to +make sure that everyone felt welcome here. If you are looking to contribute, +please make sure you are respectful to anyone participating on this project. diff --git a/FUTURE.md b/FUTURE.md index 45f14a4..856d01c 100644 --- a/FUTURE.md +++ b/FUTURE.md @@ -2,22 +2,29 @@ - [ ] Be super careful to catch all errors - [x] Rewrite readme to focus on use-cases and explaining how to implement them. -- [x] Look into supporting non-`create-react-app` uploads (Having to parse non-js files will need to be a part of this) -- [ ] With `codesandboxer`, refactor the shape of it. Take in a single object as argument, to make it easier to pass things around, and so we stop having the problem of ever-expanding functions. Move more properties into a generic `config` object -- [x] Add error boundaries around the loaded example component, to allow a better debugging experience when something goes wrong. +- [x] Look into supporting non-`create-react-app` uploads (Having to parse + non-js files will need to be a part of this) +- [ ] With `codesandboxer`, refactor the shape of it. Take in a single object as + argument, to make it easier to pass things around, and so we stop having + the problem of ever-expanding functions. Move more properties into a + generic `config` object +- [x] Add error boundaries around the loaded example component, to allow a + better debugging experience when something goes wrong. ## New packages to build -- [ ] `codesandboxer-loader` - use `codesandboxer-fs` to create the data object to be sent to codesandbox -- [ ] `gatsby-plugin-codesandboxer` - +- [ ] `codesandboxer-loader` - use `codesandboxer-fs` to create the data object + to be sent to codesandbox +- [ ] `gatsby-plugin-codesandboxer` - ## Supporting other sandbox types -We currently support react and react-typescript sandboxes -If you pass in the `template` string, you can change your sandbox kind. +We currently support react and react-typescript sandboxes If you pass in the +`template` string, you can change your sandbox kind. ## Notes made on change alongside LBatch: +``` fetchRelativePkgJSON(componentFile) compositData(entryFile, componentFile, gitConfig) @@ -29,8 +36,6 @@ fetchRelativePkgJSON(examplePath) from componentFile, fetch pkgJSON using pkgUp fetch entryFile and its dependents - - config = { gitConfig: {} | fs, pkgJSON?: {} | Promise({}), // if no pkgJSON is given, pkgUp to a pkgJSON, @@ -48,11 +53,12 @@ const parsedFile = { internalDependencies: [], extternalDependencies: {}, } - ``` + +```js const rc = findRC() -const pkgJSON = ensureProjectPkgJSON({ config.pkgJSON, rc.pkgJSON, //pkgUp.pkgJSON }) -const parsedEntryFile = ensureEntryFile({ config.entryFile, rc.entryFile, //defaultedEntryFileContents }) +const pkgJSON = ensureProjectPkgJSON({ config.pkgJSON, rc.pkgJSON /*, pkgUp.pkgJSON*/ }) +const parsedEntryFile = ensureEntryFile({ config.entryFile, rc.entryFile /*, defaultedEntryFileContents*/ }) const parsedExampleFile = getExampleFile(examplePath) const files = { @@ -60,39 +66,41 @@ const files = { 'codesandboxerEntry.js': { content: parsedEntryFile.contents }, } -return await assembleAllFilesAndDeps(files, { +return assembleAllFilesAndDeps(files, { ...parsedEntryFile.externalDeps, ...parsedExampleFile.externalDeps }, [ // ...parsedEntryFile.internalDeps, - ...parsedExampleFile.internalDeps + ...parsedExampleFile.internalDeps, ], pkgJSON, config) ``` +``` // entryFiles cannot have internalDeps import './styles.css' import whatever from './example' - +``` --- +```js files = { - 'path/to/somewhere.js': { content: '/* the file contents */' } -} + 'path/to/somewhere.js': { content: '/* the file contents */' }, +}; deps = { - package: '^1.1.0' -} + package: '^1.1.0', +}; +``` --- - -createParamsConfig = { - name -} +``` +createParamsConfig = { name } createParameters(files, externalDependencies, initialPKGJSON config ????) - ``` + +```js const sentPKGJSON = generatePkgJSON(externalDependencies, config) // ensures all packages have react and react-dom files['package.json'] = sentPKGJSON; files['index.html'] =
\ No newline at end of file + diff --git a/fixtures/importResolution/vue/B.vue b/fixtures/importResolution/vue/B.vue index 9c20654..6645b5f 100644 --- a/fixtures/importResolution/vue/B.vue +++ b/fixtures/importResolution/vue/B.vue @@ -1,10 +1,5 @@ - +