Detalhes do pacote

codesandboxer

codesandbox11.1kMIT1.0.3

Fetch files from a git repository and upload them to codesandbox

readme (leia-me)

CodeSandboxer

A quick loader to load an example into codesandbox. Takes in an entry file from github or bitbucket that loads a react component and upload it to codesandbox.

All you need to provide are the repository information, the path to the example, and the path to the package.json.

What it Does

Codesandbox collects files starting from a single example file and uploads the bundle to codesandbox, returning you the sandbox ID that these files generate. It includes by default an index file to render your example.

Why this is cool

Intelligently Fetches Dependencies

Using the example file and the package.json, dependencies that the example uses will be added to the sandbox, and everything else will be left.

Dynamic Import Following

When codesandbox is pointed at a file, it can resolve relative imports into that file, meaning that examples relying on utils or images will resolve correctly.

Customisable Usages

Codesandboxer is set up so if you provide your git information and a relative path to where the example is in the repository, it will take care of everything for you. Alternatively, if you have some of the content, or wish to edit it (for example replacing particular relative imports before upload) you can deeply customise the information before it is sent.

You can use this purely to help format your files for codesandbox, or you can rely much more heavily on it to do work for you.

API

Quick Start

There is an assumed workflow to codesandboxer:

import {
  fetchFiles,
  finaliseCSB,
  sendFilesToCSB
} from 'codesandboxer'

/*
fetchedInfo is an object containing `files`, the internal exports of the target file, and `dependencies`, the external dependencies of all files.
*/
let fetchedInfo = await fetchFiles({
  examplePath: 'fixtures/simple'
  gitInfo: {
    host: 'github',
    account: 'Noviny',
    repository: 'codesandboxer',
  }
})

// This also returns a finalised files and finalised dependencies property, in case you want to introspect those before sending.
let finalisedInformation = finaliseCSB(fetchedInfo)
let csbInfo = await sendFilesToCSB(finalisedInformation.parameters)
console.log('Our sandbox\'s ID:', csbInfo.sandboxId)
console.log('Simple sandbox URL:', csbInfo.sandboxUrl)

In addition to these three main functions in the workflow, there are also several helper functions that can be used separately. We are going to look at the three main functions first, then the helper functions.

fetchFiles()

fetchFiles takes in the necessary information to assemble your files bundle, and returns a promise with with an object that contains:

files: An object of the files that are to be included in the bundle, with the entry file named as 'example.js'

dependencies: An object containing all the external dependencies that will be required from npm to assemble your package.

It takes a single argument which is an object, the properties of which are detailed below.

Note that only the examplePath and gitInfo are required. Everything else can be inferred.

examplePath: string

examplePath is always required, and is a path relative to the root of the git repository. Assuming no example is provided, this file will be fetched from github or bitbucket.

gitInfo:

An object containing the information to make fetch requests from github or bitbucket. There are three mandatory properties and one optional property.

  • account: the name of the account the repository is under
  • repository: the repository name
  • host: where your content is hosted, accepts 'bitbucket' or 'github'
  • branch: optionally you can define what branch to pull from (fun fact, also accepts git hashes). Defaults to master if no branch is required.

This information is needed to fetch any additional files needed.

pkgJSON

This is an optional property, that can include a package.JSON's contents as an object or a string which is the path relative to the git source directory to fetch the package.json from your git repository. pkgJSON finally accepts a promise that can be resolve to either of these two other types.

The contents of the eventual resolved package.json will be used to get the correct version ranges of packages your example is relying upon, and assemble a package.json for codesandbox to use in pulling them in.

importReplacements: Array

importReplacements are used before parsing what imports are needed by a file, to allow you to keep control of what files are uploaded.

The biggest use-case of this is if you are relying on your src/ directory, but want to use your package from npm in the uploaded example.

If you pass in a path ending in a *, it will replace all that match the start of the pattern with the new pattern.

We also expose the logic that replaces imports as replaceImports(), in case you want to transform a file before passing it to us.

example

If you do not want the example content to be fetched (for example, you have access to the raw code, or want to transform it yourself before analysis), you can pass in the example file as raw here (just a string). You can also pass a promise that resolves to an example's file's contents.

extensions

An array of extensions that will be treated as javascript files. For example, if you pass in [.jsx], when loading files, we will attempt to fetch .jsx files as well as .js and .json files. The extension type of your example is automatically added, so if you pass in the examplePath my/cool/example.jsx, you will not need to pass in the jsx extension.

If your example file is fo type .ts or .tsx both are added.

finaliseCSB(compiledInfo, config)

The FinaliseCSB function is used to generate a parameter hash of the file contents that can be sent to codesandbox using sendFilesToCSB. It takes in the result of fetchFiles, however is separate so you can intercept files and either examine or modify them before it is sent to codesandbox.

The config object is optional, and can have any of the following properties:

name

The name for the sandbox once created.

extraFiles

Pass in files separately to fetching them. Useful to go alongisde specific replacements in importReplacements.

The shape of the files object is

{
  fileName: {
    content: string
  }
}

The filename is the absolute path where it will be created on CodeSandbox, and the content is the file's contents as a string.

If a fileName exists in your provided files, it will not be fetched when it is referenced.

extraDependencies

An object with packages formatted in the same way as the dependencies in a package.json which will always be included in a sandbox, even if it is not found within the example's tree.

sendFilesToCSB()

Accepts the generated parameters from the codesandbox API, and posts them for you, returning a promise that resolves to an object that has both the sandbox ID, as well as the base URL to open the sandbox on the example page.

parseFile(file, pkgJSON)

parseFile is our internal method for finding all the import information about a file.

It accepts a raw file, or a promise that resolves to a raw file, and a package.json as an object, or a promise that resolves to a package.json as an object.

It returns an object with the shape:

{
  file: // the raw file code
  deps: // the external dependencies of the package with the version range from the package.json
  internalImports: // a list of the internal imports that the file relies upon.
}

replaceImports(code, Array<[old, new]>)

The internal method we use to replace imports. This takes in a raw file, and an array of imports to replace. The first item in the array is what will be replaced, and the second is what it will be replaced with.

If you pass in a path ending in a *, it will replace all that match the start of the pattern with the new pattern.

fetchRelativeFile( path, pkg, importReplacements: Array<[string, string]>, gitInfo, config)

This function takes in a path to a file relative to the git route, and along with the git information, fetches. It will also replace the imports as provided for javascript files.

It return a promise with a parsed file which is an object that looks like:

{
  file: string,
  deps: { [string]: string },
  internalImports: Array<string>,
  path: // the new path that this file will be added to within codesandbox, and which other files can now use as an importReplacement,
}

Currently the shape of the config object should be { allowJSX: boolean }. If the config object is not provided, this defaults to false.

getSandboxUrl(id, type)

Passed in a sandbox id, return a url to that sandbox. Optionally takes in a type which can be used to make the url an embed url by passing in the type 'embed'.

Things to do better

Support commonJS modules

Currently we are scanning for import statements, and commonJS requires are not supported.

Support beyond react

The principal developer of this works in a react context, however the core good features (file fetching from relative imports, and packages, parsing all those files into a bundle codesandbox understands, posting to codesandbox) are valuable to any codesandbox project.

If you want to use codesandboxer to upload something other than react, please get in contact with us so we can help out.

Does not play nicely with inline webpack loaders

If you are using inline webpack loaders, we don't know how to parse those. This is not on our roadmap to support.

Designed browser-first

As codesandboxer is designed to operate from the browser, it's not using an AST to parse the files it is reading. If you are using it in a node context, implementing this functionality using an AST generator such as babel will likely lead to safer, more precise code.

changelog (log de mudanças)

Changelog

1.0.3

Patch Changes

  • [patch]2c210fa: Last publish did not have correct dists - republishing

1.0.2

Patch Changes

  • [patch]a4400e5: Fix bitbucket API to use the 2.0 bitbucket API

1.0.1

  • [patch]cedfb74:
    • Update repository references to point to new home.

1.0.0

  • [minor]0b60604:
    • Centralise decision around what template to use into one location, and allow it to be exported for downstream packages.
  • [major]b46e059:
    • Move codesandboxer and codesandboxer-fs to first major version, as they exist in a fairly stable and used state.

0.7.2

  • [patch]82a4f5f:

    • Fix typo that was stopping react and react-dom being ensured by the finalisation.

0.7.1

  • [patch] af01387:

    • Share information on the main example's filename and use this in the url

0.7.0

  • [patch] 4b2b662:

    • Reorganise how templates are stored This is a bunch of changes that should mostly only be relevant internally.

      First is that there is a /templates directory instead of constants.js to store templates in. This makes it easy to read a template an easy to see how to add a new template

      Secondly, while codesandboxer-fs still has its own templates, it inherits templates from codesandboxer meaning that a template can be added in one and flow down to the other.

      This sets up for Vue sandboxes.

  • [minor] 9db3c25:

    • template is now passed to 'finaliseCSB' as part of the first object not the second object.
  • [patch] 4b2b662:

    • Add Vue template to upload vue sandboxes In addition, codesandboxer will do its best to autodetect if it is processing a vue, react, or react-typescript sandbox, and use the preferred sandbox unless otherwise specified.

0.6.1

  • [patch] d0c0cef:

    • Add basic support for sass and scss being uploaded

0.6.0

  • [minor] 🎉 ADD TYPESCRIPT SUPPORT 🎉 (comes with auto-detection of typescript examples)
  • [patch] Use path-browserify for most path actions, making the code more reliable
  • [patch] Import statements now no longer need a variable declaration to be parsed
  • [BREAKING] Remove the allowJSX config option - this is replaced by extensions, an array of allowed additional extensions
    • the file type of the example file is automatically added, so if your example is a .jsx file you no longer need to pass anything in. If it is a .ts or .tsx file, it will add both extensions as allowed extensions. Overall, you probably don't need it.

0.5.0

  • [minor] Allow the loading of css files; convert the json loader to a generic raw loader becc64e

0.4.0

  • Rewrote logic that handles parsing imports. As well as just being a bit more secure, it now correctly support:
    • require statements as well as imports
    • export a from 'b' syntax

0.3.0

BREAKING - fetchFiles now returns just the { files, deps } object, which was previously returned as files. It no longer return parameters or name. BREAKING - finaliseCSB is now exported. The API for this function has changed dramatically as well. This function accepts the mix of files, deps, and several other passed in values, and is used to generate the parameter hash.

The new workflow goes fetchFiles() -> finaliseCSB() -> sendFilesToCSB, with the ability to put your own logic in between these.

FEATURE - resolvePath is now exported. This is to support codesandboxer-fs, which wants to rely upon it.

0.2.2

Use the formData package for deploys instead of the native web formData. This is to allow codesandboxer to be node-compatible.

0.2.1

An internal call of fetchRelativeFile was not being passed the new 'config' object, causing an error in file fetching. It is now being passed the correct object.

0.2.0

Add a new argument to fetchFiles, and fetchRelativeFile that is a config object.

To the config object add allowJSX as a property with a boolean value.

Codesandboxer can now load jsx files if you opt into it.

  • allow loading of JSX files
  • Add tests using fixtures in repo to test file resolution

0.1.1

Stop using * import due to struggles with transform-runtime

0.1.0

Be extracted from react-codesandboxer