I do not seem to get the same visuals as others when creating a plugin. There is no progress indicator and some emojis seems to be missing:

So I create a plugin and it gets added to the main app. What if this plugin should not be open sourced? How do we I move it to an internal repo and stil use it in the main Backstage app?

This needs to be documented, and ideally supported in the CLI.

Use world wide time zones instead of Spotify focused.

Should be as forwards-compatible as possible. Few references to files etc.

• Update architecture image

There's no way to include static assets in plugins right now

Replace internal implementation of DataGrid with some other open alternative. Having a simple-to-use grid component is essential for easy development.

See console output

--- backstage/frontend ‹master* ?› » yarn create-plugin
yarn run v1.21.1
$ yarn workspace @spotify-backstage/cli build && backstage-cli create-plugin
$ web-scripts build
? Enter an ID for the plugin [required] testPlugin

🧩  Creating the plugin...

 Creating the plugin directory:
  creating	/packages/plugins/testPlugin ✓

 Reading template files:
  reading	14 files ✓

 Setting up the plugin files:
  processing	README.md.hbs ✓
  processing	package.json.hbs ✓
  processing	jest.config.js ✓
  processing	tsconfig.json ✓
  processing	jest.setup.ts ✓
  processing	index.ts ✓
  processing	plugin.ts.hbs ✓
  processing	plugin.test.ts.hbs ✓
  processing	ExampleFetchComponent.test.tsx.hbs ✓
  processing	ExampleFetchComponent.tsx.hbs ✓
  processing	index.ts ✓
  processing	ExampleComponent.test.tsx.hbs ✓
  processing	ExampleComponent.tsx.hbs ✓
  processing	index.ts ✓

 Building the plugin:
  executing	yarn ✓
  executing	yarn build ✗

Could not execute command yarn build: Command failed: yarn build
error Command failed with exit code 2.


🔥  Failed to create plugin!

? It seems that something went wrong when creating the plugin 🤔
Do you want to remove the following directory and all the files in it:
/Users/bil/Development/github.com/spotify/backstage/frontend/packages/plugins/testPlugin Yes

🧹  Cleaning up...

 Removing plugin:
  deleting	/packages/plugins/testPlugin ✗

Failed to cleanup: ENOTEMPTY: directory not empty, rmdir '/Users/bil/Development/github.com/spotify/backstage/frontend/packages/plugins/testPlugin'
✨  Done in 45.26s.

• Visualise project roadmap and which parts are available now
• Don't use REST API -- only REST

Example: https://github.com/spotify/scio/blob/master/CONTRIBUTING.md

Any reason why these steps could not be automated? I don't see any situations where you create a new plugin and don't want to try it out.

The following code does not render correctly:

   <Page theme={theme.home}>
      <Header
        title={profile ? `Hello, ${profile.givenName}` : 'Hello'}
        subtitle="Welcome to Backstage"
      >
        <HomePageTimer />
      </Header>
      <Content>
        <ContentHeader title="Current Set">Something</ContentHeader>
        <Grid container direction="row" spacing={3}>
          <Grid item xs={6}>
            <Typography variant="h3" style={{ padding: '8px 0 16px 0' }}>
              Things you own
            </Typography>
            <InfoCard maxWidth>
              <SortableTable data={data} columns={columns} orderBy="id" />
            </InfoCard>
          </Grid>
          <Grid item xs={6}>
            <SquadTechHealth />
          </Grid>
        </Grid>
      </Content>
    </Page>

We should set permissions on our Figma files to world-viewable and allow public comments

Currently yarn && yarn create-plugin. Couldn't yarn create-plugin run the same thing as yarn so that it can be removed?

Can we use free versions of icons8 and reuse our internal wrappers for those?

Also, do we need to preface all plugin names with plugin-?

Introduce a site config file (example) so that people deploying Backstage can customize things like:

• Site name (everyone may not want to use "Backstage")
• Site logo
• Proxy URLs etc
• Timezones for Homepage headers
• GitHub URL
• ...

Add new bursts that are not Spotify official ones, but still give the same rich feeling.

We need to have Apache license headers at the top of all relevant files, and we should have lint rules enforcing their use.

https://backstage.spotify.net/docs/foss/guides/releasing/
http://www.apache.org/licenses/LICENSE-2.0#apply

one possible solution:
https://github.com/nickdeis/eslint-plugin-notice

which was successfully used here and recommended by the repo owner:
https://github.com/spotify/NFPlayerJS

Custom styling is required for a plugin to render correctly with a header and content:

const useStyles = makeStyles<Theme>(theme => ({
  mainContentArea: {
    overflowX: 'hidden',
    overflowY: 'auto',
  },
  pageBody: {
    padding: theme.spacing(3),
  },
}));

const ExampleComponent: FC<{}> = () => {
  const classes = useStyles();
  return (
    <Page theme={theme.home}>
      <div className={classes.mainContentArea}>
        <Header title="Welcome to stefan-demo!" subtitle="Example"></Header>
        <div className={classes.pageBody}>
          <Typography variant="h3" style={{ padding: '8px 0 16px 0' }}>
            Page title
          </Typography>
          <InfoCard title="Information card" maxWidth>
            <Typography variant="body1">
              All content should be wrapped in a card like this
            </Typography>
          </InfoCard>
        </div>
      </div>
    </Page>
  );
};

You should not need divs with custom styling. This should all be taken care of by the core components such as Page and Header.

At present, there is no validation on the plugin ID when creating a plugin on the command line.
I was able to create plugins with names:

• $ &&!@#%!#%SD_-?><~+
• ~

Better signal the alpha stage by staying below 1.0.

We need to reset versions back to 0.1.0 or similar, TBD, and unpublish all npm packages with higher versions.

Possible choice: https://github.com/mbrn/material-table

For a properly nice open source project I think the makefile should support other platforms, or at the very least it should be documented what tools are needed to install.

It is useful for packages to be able to see their own test coverage, and to enforce limits on it.

Backend parts are not done yet. No need to have them in the beginning of the README.

The e2e tests currently fail
https://github.com/spotify/backstage/runs/500338208

because of #215

error Couldn't find package "@spotify-backstage/cli@^1.2.0" required by "@spotify-backstage/[email protected]" on the "npm" registry.

lerna won't update this for us. Let's update the scaffolder to inject its own current package version instead.

https://stackoverflow.com/questions/9153571/is-there-a-way-to-get-version-from-package-json-in-nodejs-code

Today:

Should be (without the table header -- which is broken right now):

From repo Settings:

Social preview
You can upload a social image, but it will not be visible publicly while spotify/backstage is private.
Upload an image to customize your repository’s social media preview.
Images should be at least 640×320px (1280×640px for best display).

Configure CODEOWNERS and define how external (non-Spotify team) can add parts of the repo.

Should these really be here? @Rugvip

https://github.com/marketplace/dependabot-preview

Don't use the Home theme.

Right now imports always need to be relative. Setting path/rootDir params in tsconfig works for the compiler, but produces broken build output.

Generate plugin-info.yaml or similar.

Include following metadata:

• Company name
• Author
• Description
• ...

I don't really understand what this means Run yarn start in the plugin directory to start it:

Maybe cd into that newly created repo?