Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Archive the repository if the project is dead. #13393

Open
retsimx opened this issue Oct 3, 2023 · 10 comments
Open

Archive the repository if the project is dead. #13393

retsimx opened this issue Oct 3, 2023 · 10 comments

Comments

@retsimx
Copy link

retsimx commented Oct 3, 2023

Archive the repository if the project is dead.

@rjcoupe
Copy link

rjcoupe commented Oct 4, 2023

It seems alarmingly uncommunicated that CRA is unmaintained - the README.md makes no mention of it, indeed I only noticed the issue due to a message re @babel/plugin-proposal-private-property-in-object.

At the very least, the README should make the project's lack of active maintenance clear (or, if I've just missed it, clear front and centre).

@skagedal
Copy link

Yeah, I also noticed this after doing yarn create react-app some-app--template typescript and then running yarn start:

One of your dependencies, babel-preset-react-app, is importing the
"@babel/plugin-proposal-private-property-in-object" package without
declaring it in its dependencies. This is currently working because
"@babel/plugin-proposal-private-property-in-object" is already in your
node_modules folder for unrelated reasons, but it may break at any time.

babel-preset-react-app is part of the create-react-app project, which
is not maintianed anymore. It is thus unlikely that this bug will
ever be fixed. Add "@babel/plugin-proposal-private-property-in-object" to
your devDependencies to work around this error. This will make this message
go away.

It seems this message was added here. Wonder where they got the information.

@SourceCipher
Copy link

CRA has been dead for a long time. Issues were bounced off with some bots marking it as stale or just force closing it without any resolution because thats how they felt doing it.

This repo should be marked as not maintained anymore for sure.

Anyone thinking of creating new project with CRA should reconsider it for sure and use something like Vite instead.

@violet4
Copy link

violet4 commented Feb 16, 2024

😩 poor unsuspecting devs.

image

image

image

@pseidemann
Copy link

hi @violet4,
not sure what your point is, could you elaborate?

the project works fine for me. I don't mind if there is not a new release every week. unless it breaks and nobody fixes it, why archive it? maybe some day someone wants to take over maintenance. if we archive before that, the project's death will be a self-fulfilling prophecy.

@violet4
Copy link

violet4 commented Feb 16, 2024

@pseidemann fresh install 8 vulnerabilities, 6 high

image

@pseidemann
Copy link

hi @violet4,

just note that these vulnerabilities are probably not very critical, since the code you generate with this "tool" is running in the browser only. so ultimately your browser decides if using your app is safe.

@violet4
Copy link

violet4 commented Feb 16, 2024

if we archive before that, the project's death will be a self-fulfilling prophecy.

this ticket is titled "Archive the repository if the project is dead." but i personally never made a claim that it should be archived.

i wish CRA were more upfront about its current limitations, especially considering that it's put out by a very large organization (fb/meta) which has many smart developers. it's incredibly disorienting to use a tool by fb/meta with 879 contributors, 1.7k issues, 464 PRs that makes no mention of its current lack of maintenance, which then spits vulnerability messages on a fresh install.

just note that these vulnerabilities are probably not very critical

as a newbie to NPM+React on a work project over a year ago, not realizing there are alternatives to CRA (not even knowing what CRA itself truly is), i reluctantly ignored the messages hoping "these vulnerabilities are probably not very critical," but even now, don't know how i would go about analyzing that claim, besides going through each dependency individually.

so ultimately your browser decides if using your app is safe.

plenty of code "looks safe" from the browser perspective but has vulnerabilities. sure, the browser has XSS protections, but that's only one class of issues that the browser tries to protect against. vulnerabilities can be incredibly complex/nuanced and result in major issues even though the code "looks safe" to execute. every user who browses the web is taking a risk every time they visit a page, click a link, etc. so.. it's 100% the browser's responsibility to protect users? browsers work very hard at security but why should a developer knowingly (or unknowingly, in the case of a newbie CRA user) risk including vulnerabilities in their software?

it sounds like you made a conscious decision to claim willful ignorance at vulnerability warnings, which may be fine for you, your workflow, your project/job type, use case, attack surface, etc.. but why encourage others to do the same or assume it shouldn't matter for others?

if i want to spin up a cute little react project in 10 seconds flat and security doesn't matter as i create the nth todo app, sure i might use CRA, but i want to know the caveats upfront before i begin. otherwise i feel misled and then feel distrust. there's no hint at the current state of the project on the website https://create-react-app.dev/ , in the repo, etc.

@pseidemann
Copy link

it's 100% the browser's responsibility to protect users?

it pretty much is (but obviously cannot do that 100% of the time). the browser cannot trust websites (and your CRA app), otherwise attackers will exploit.
additionally for the same reason, your backend cannot trust clients (browsers/users/attackers).

CRA only creates a static HTML/JS/CSS bundle which will be served to the browser.
if, for any reason, these static files behave malicious inside some browser, your backend is now prepared for that anyway.

the browser has XSS protections

the browser actually doesn't protect against xss. it only protects against cross-origin requests (to some degree).

react has some good xss preventions but you can still write unsafe code with some effort (using innerHTML/dangerouslySetInnerHTML etc.).

xss unfortunately can still happen if all your deps are not vulnerable according to npm. often it is a programming error by the developer.

@skagedal
Copy link

Not sure if this discussion is relevant. Is the project maintained or not? If not, it would be nice if this was mentioned in the README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants