you are referencing to yourself, so I will reference to myself too:

this thesis sounds like "OK, you are in a dark room anyway, so let's throw away the last candle"

feat: Add linters

Merge pull request #62 from lidofinance/add-linters

feat: Add linters

PNPM is great project but for developers in Russia or Belarus it is a significant risk to use it: https://news.ycombinator.com/item?id=30921103.

I totally understand the author and feel bad about everything happening, but I have team members who are working from this 2 countries (and other CIS countries) for various reasons - from issues with getting international passport after being forced to serve years ago (and forced into getting so-called secrecy form, which bans you from leaving the country for 10+ years) to parents who require medical attention, so people can only leave country knowing they will make their parents die slowly, as no one will take care of them (as they literally fight for medical supplies every week or two, driving all around the town in search of deficit drugs).

I'm big fan of Rush (which is significantly ahead all other solutions) but PNPM is risk for our team now, and yarn/npm solutions are problematic to use due to multiple minor bugs in everyday use, so I honestly have no idea what to do - migrate to lerna/nx/turporepo, and write ton of replacement code on our own? Wait for something else to happen and resolve the case? No idea. Just very sad - not about rush itself, of course.

You are right about trackers, thank you.

Zero offence is intended, just risk management - that's why I came with this issue.

ummmm... I'm not saying about toString, I'm saying about stack removal here.

I'm certainly not opposed. We pivoted away from keeping NPM because of an increasing set of bugs that we weren't able to work around, and neither NPM nor Yarn (without Yarn PnP) supported the same level of strict dependency sandboxing that PNPM supports. We haven't looked into either in a few years, so NPM's stability may have improved, but if it hasn't, it'd be probably more worthwhile to focus on Yarn.

@Jabher - Would you/your team be interested in working on this?

I personally would be happy to contribute again (if I have a time) but sadly I'm afraid I will not be able to contribute in full.

However, my team has limited capacity :(

Isn't it only the PNPM website that is blocked? The notice seems to indicate that developers can still install the package from npmjs.com and it should still function correctly. Also, the website content is stored on GitHub.

This is correct ATM but at march there was a lot of cases like this https://portswigger.net/daily-swig/npm-maintainer-targets-russian-users-with-data-wiping-protestware. So in terms of risk management even version-lock is not an option - as long as there is no security audit on that version.

However, Zoltan (author of PNPM) is discussing about NPM registry lock in terms of not "this is not we want" or "this will break ton of things" but "we have no control on that". https://twitter.com/ZoltanKochan/status/1498310500836380683

For me it sounds like "if we will find more ways to make issues to russian IPs we will probably apply them too" so that's a risk - even for ones who already left the country, as they are sometimes using private or public VPNs to access gov-services - even simply for getting documents for other residency

support for sidenotes field

yes, I was mostly speaking about second case (as this is the most frequent integration case).

Do you understand that this thesis sounds like "OK, you are in a dark room anyway, so let's throw away the last candle"?

Web is already complicated and confusing, growing up as a developer is way harder than 5 or 10 years ago, it is way more confusing in complex manner (not "why 1+1 is 11", but "why I cannot access credentials when I pass origin * to CORS", or "why frame rate drops when I try to animate DOM element with shadows, which leads to lower google score and worsen SEO", or "how to implement PWA when iOS is removing cookies from it every week", or "how to debug 3rd party services which are hijacked by country-level censorship and/or provider placing ad spam instead of content I've provided") and this proposal is making things worse.

Please, lit the fires, not shut them down. Web world is already hard and obscure in many means, including browser wars - on OS level now, not like "in goodies-oldies 90s" when everybody just had proprietary features, including corporates fighting for ROI and MAU, and personal data of each of us, governments trying to prevent their citizens to access the truth.

I'm sure we all here love web, but this proposal can be one of steps that will convert free web application users - like GitHub we're using now - into fully-company-controlled applications, because this can make web development harder. We all here do not know the impact, but we know there will be impact.

10% web development costs raise will cause some companies to build on iOS or Android, not web. Please, rethink this proposal. We need web to be clear, understandable, readable, supportable, not mysterious and obscure.

PNPM is great project but for developers in Russia or Belarus it is a significant risk to use it: https://news.ycombinator.com/item?id=30921103.

I totally understand the author and feel bad about everything happening, but I have team members who are working from this 2 countries (and other CIS countries) for various reasons - from issues with getting international passport after being forced to serve years ago (and forced into getting so-called secrecy form, which bans you from leaving the country for 10+ years) to parents who require medical attention, so people can only leave country knowing they will make their parents die slowly, as no one will take care of them (as they literally fight for medical supplies every week or two, driving all around the town in search of deficit drugs).

I'm big fan of Rush (which is significantly ahead all other solutions) but PNPM is risk for our team now, and yarn/npm solutions are problematic to use due to multiple minor bugs in everyday use, so I honestly have no idea what to do - migrate to lerna/nx/turporepo, and write ton of replacement code on our own? Wait for something else to happen and resolve the case? No idea. Just very sad - not about rush itself, of course.

You can transpile out any source code or expose things that are hidden - it all still has a purpose.

I provided multiple examples of code you cannot transpile - from browser plugins to 3rd party libs. What is even worse, browser plugins are loading scripts in separate context and you are physically not able to load your own transpiled version into this context (this is a security measure - e.g. look at Metamask). By blocking the ability to read the stack traces you are breaking the chance to debug interactions between plugins and libs

update config

That is exactly what I'm talking about. Developers are, often, optimists. I totally understand this beautiful idea "we can make polyfill that acts like original code, even in stack traces". However... polyfill.io has 800+ closed issues. Core-js has same-scale numbers. I understand that not all of them are bugs, some are improvements or proposals, however, it is definitely not normal to expect that there will be no bugs. And with no idea how to debug - this will be catastrophic. Just imagine that there will be a bug in polyfill on specific OS/browser that nobody is able to see even in stacktraces? And if this proposal will be accepted, this definitely will happen, and not even once, but multiple times - just by law of large numbers, and nobody will even have a clue what is happening, if it is provided code (like Google Analytics).

Moreover, speaking of async-to-generator approach - so, you are basically saying that some companies are using regenerator-ish approach not as a way to support older browsers, but as a way to obfuscate stack traces? Sounds a little bit crazy, but I think that some companies can really act in that manner.

Also, generators approach allow to at least see a generator function and have slightest clue what was happening (and place breakpoints). This approach cuts all chances.

feat: update steth ABI

BREAKING CHANGE: This commit only rearranges two abi elements to start a publish workflow

Merge pull request #54 from lidofinance/feat/steth-abi-update

feat: update steth ABI