No option to remove/delete a component from OC during product development phase

[JuniorDev4Lyf]

The other day i ran into a problem. Our team has been following a process where we usually publish our components with 1.* versioning pattern. One of our team members published the same component but with a higher version 6.0 by mistake.
In a usual development environment i would want to remove the ill versioned component (delete)
and continue my development versioning with the next consecutive number say 1.7 after 1.6.

How do i remove the ill versioned components from the library as well as registry!

I do respect the idea behind immutable components. As much as i want to have it this way in a production environment, i would also like to have an option to delete/unpublish/remove the components from oc registry n library during my development phase. Having said that, there should also be a configuration setting to disable to option for production environments.

Don't you think it's a must have feature/option in this kind of framework. Please share your thoughts.

[mattiaerre]

thanks for this issue @NapoleanReigns and sorry for the delay. The way we recommend to deal with an unwanted component, is marking it as "deprecated" and so far this way worked quite well for us. But it looks like other OpenComponents users might be interested in having this possibility. I am personally not against adding this feature. Let's see if someone else would like to add more on this.

[matteofigus]

Hi @NapoleanReigns

The way we handle this, is to have publishing done by our CI - and each component has a Pull Request including the version upgrade. This allows us to avoid situations like someone erroneously publishing a component with the wrong version. If you ask me, that's the way I would recommend to setup your pipeline. Delegating to automation the publishing also allows you to make sure nobody publishes faulty components from his machine (perhaps with unchecked source code) and you can make sure all the tests run before your change to go to prod.

Nevertheless, if you want to "unpublish" a component manually, because something bad happened, you can at the moment

1. Remove the folder manually from S3
2. Bounce all the Registry instances to clear the cache
3. You should be fine

Now let's talk about the "unpublish" functionality aka "deprecate".
What I fear about such thing (automating the real removal of the thing) is to get to a recursive process of - I made a mistake => I published => Let's unpublish => Wait I made a mistake on unpublishing => I'm screwed 👍
So, in short, I believe a good feature for the deprecate would be something like marking it as deprecated, but not really removing it.

This is my proposal:

CLI

oc deprecate my-component 1.2.3: This would "flag" the component as deprecated - which wouldn't delete it, but would mark it as "not available". Publishing again my-component@1.2.3 would fail, but my-component@1.2.4 would succeed.
oc undeprecate my-component 1.2.3: same as before the deprecation
Other options for deprecate/undeprecate could be block/unblock or lock/unlock? Opinions?

Registry

Let's imagine I have my-component@1.0.0 and my-component@2.0.0 (deprecated)

• curl https://myregistry.com/my-component (latest) => would resolve 1.0.0
• curl https://myregistry.com/my-component/2.0.0 => would 403 (Forbidden)

I think a mechanism like that would be really cool also in case of security issues. If you would find a vulnerability or a serious bug in a component, you could just deprecate it live, basically "automatically" rolling back (if consumers consume weak versions of it, for instance 1.x.x`)

[nickbalestra]

I agree with @matteofigus, but I'll rather not use the deprecation naming, as it will result in error for consumers consuming a specific version and that's a bit outside of the deprecation meaning to me. I totally see the point @NapoleanReigns makes, thanks for sharing!. I'll therefore suggest we name this feature similarly to how React handle such edge-case APIs (see their
__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED), perhaps something like block-not-use-or-you-will-be-fired ?

I'll also suggest we keep the same command for both blocking and unblocking but simply passing a flag, i.e --remove

oc block-not-use-or-you-will-be-fired my-component 1.2.3
oc block-not-use-or-you-will-be-fired --remove my-component 1.2.3

This is ugly by design as this shouldn't be a feature but merely an extra measure for the cases like the ones illustrated by Sourabh (also cause they could be avoided by setting up a different publishing pipeline as Matteo pointed out)

[denysvitali]

A similar feature may be useful when you have to disable / remove a certain component version from the registry.
Let's say you have a component-name (v1.0.0) which has some server.js code that is remotely exploitable (like an SQL injection, a RCE, you name it).
Your team fixes the security issue in v1.0.1 and push the newest version to the registry; the clients which adopt the v1.0.x / v1.x contract will have the latest v1.0.1 version, but on the registry the v1.0.0 (vulnerable) version is still available.

Without a command to to disable a specific component version, when a component is "compromised" you'll need to manually delete the affected version(s) by removing the folder as suggested here by @matteofigus.

[kmcrawford]

I setup our pipeline so that branches are automatically set to experimental and are only allowed to be deployed to the dev registry with a name of {branchName}-{componentName}. Once the branch is merged to master and the branch is deleted, the branch component files are removed from the CDN by a clean up job. The pipeline also auto increments the patch version if it already exits in the registry.

[kmcrawford]

I’d like to revisit this. I do like @matteofigus suggestion of deprecate and undeprecate. Mostly for the case of a component is thought to be complete. Gets published & and the team finds an issue and quickly needs to rollback.

Right now the only solution is to delete and bounce, which can have negative effects for a short while between the delete and the bounce. (Which is how we clean up branches in our dev env with an automated “janitor” process).

I see @nickbalestra ‘s concern for consumers that are looking for an specific version vs a X version.

Perhaps there can be a compromise where users requesting X version to not get the latest deprecated version.

1.6.2 published
1.6.3 published
1.6.3 deprecated
1.X.X requested 1.6.2 served
1.6.3 requested 1.6.3 served

A possible concern is if no prior version exists.
2.0.0 published
2.0.0 deprecated
2.X.X requested
? Served