Test components in a local 'remote' scope, before uploading full versions to the cloud

[benjgil]

Why Do I Need To Locally Test Components As If They Were In a Remote Scope?

While the local dev server mimics almost entirely what you will see when you export a component to a remote scope - meaning you can iterate locally and only once you're happy with how your component looks, then version and export to the remote - there are still a few scenarios that can cause differences between the dev server and a true bit scope, and that's where this article comes in.

If you're seeing an example of this - for instance, when configuring Context providers for compositions via and env - then it is highly recommended to render the component in a manner which reflects how it will look on the remote scope, and then once your components are as you want them to be, export them to the production remote scope (e.g. bit.cloud).

Two Options

Option 1 (recommended) - simple and doesnt require a locally-hosted scope

This option is very simple and based on a single piece of information - once bit runs bit tag, the output of that is stored on a local scope and can be rendered locally without having to export it. This local rendering will be 1:1 how your component's preview (docs and compositions) will look on the server.

The way to view a locally tagged version of your component/s, is to simply run the local dev server bit start. Once it is running, navigate to the component you want to view, and click on the version dropdown which will currently read 'workspace'. There you can select the newly tagged version and then you will see your component rendered exactly how it will look if and when this tagged version is exported to the remote scope.

Option 2 - Testing Via Locally-Hosted Scope

One thing to keep in mind, is that when you test against a locally-hosted scope (instructions in a bit), you are essentially creating and exporting newly tagged versions of your components, which you may not (or almost certainly don't) want to do on your actual repo. If you did, then your bitmap will show new versions, but those versions have only gone to the locally hosted scope. Then when you try to re-sync with your actual Scope on the cloud there will be version conflicts and the such.

Isolated Testing

So there are a couple of pretty quick and simple options for isolating your test iterations, and then restoring back to your code:

1. New branch - do the changes, iterations, tagging and exporting on a new branch. This way the bitmap is only updated on that branch and then you can merge the code changes back to your main branch without committing the bitmap file. Then you'll have a new version of your components which has been verified to work and look as expected on a remote Scope. You can tag and export as if you were never gone from this branch.
2. Iterate in an entirely new directory. This reduces the potential that you'll by mistake commit the .bitmap file, but is more of a pain to copy-paste files back to your workspace.

You can also clone the repo, but IMO that's unnecessary repo cluttering as a new branch should be just as effective in isolating the test versions of your components.

Locally hosted remote scope

On this my colleague @debs-obrien has written an extensive post here, outlining how to configure a locally-hosted scope and the various options you have. Please see the linked discussion for details.