No inconvenience—I like these kinds of things but then another question had a typo in it (varx instead of var x) and one of the options was ‘Error’ but again that was incorrect. It’s probably worth running these snippets just to make sure :)
The issue I usually have with these logging libraries is that they often don’t handle structured data well, which is something that’s commonly needed in a logging library.
For example, it’s fine for log entries to be a string when logging to console or a text file, but if you add a sink that logs to a database, service (Sentry, Loki, NewRelic, whatever), or JSON file, you’ll generally want some sort of structured data. At the minimum, you’d want the format string (e.g. “Unable to find {id}”) and the variables (e.g. {“id”:123}) to be stored separately, so that you can get aggregated counts for how often each error is being thrown regardless of the variables.
Big fan of that. Most of recommended Biome rules work for me, but I’ve worked with different projects, that have a lot of pretty specific style preferences. This is going to make migrations so much easier
Rollup is one option that will fit a lot of situations, but there are other ways to bundle a library/module that focus more on how you want to use it. Is it used by other libs, by a UI application, etc.
For both frameworks, the directory structure controls the URL unless there’s an exception I’m unaware of.
One way to forward the cookie may be to read cookies from the API response headers and write them using the following documentation: nextjs.org/docs/app/api-reference/…/cookies
Quite a loaded changelog. The removal of formatters is appreciated, because half of my old configs were just disabled rules, in order to avoid conflicts. The new and updated rules are pretty solid too.
I will have to say though - I’ve migrated my projects to Biome, and i’ve been a lot more happy with it so far. My only complaint there is the editor plugins that still need a lot of work
We’re still using Yarn and Lerna on our projects at work. We’re about to start a fresh new build though and have been looking at NX for the new setup. From our PoCs it works a lot better. Lots less rebuilding and bootstrapping with it’s built-in caching. Looking forward to implementing it properly.
Still want to look into Yarn 2 and see if it works with it.
You only need to worry about devDependencies vs dependencies if you are going to publish the project you are working on as an npm package. If you are making a webapp or something else that you will run, then it doesn’t matter.
Exactly. If nobody ever runs npm install <yourpackage>, don’t worry about it. (Like, literally, you can put half your dependences in dependencies and half in devDependencies and it will be fine.)
If you do, then every dependency the person who runs that command doesn’t necessarily need goes into your devDependencies.
This isn’t exactly the case but yes, I would prefer to keep the dependency list as small as possible, mainly because I’m subject to security scans and I don’t want things to get held up because there’s a vulnerability in my linter.
Are you using Node.js on the backend, or are you just using JS for the frontend?
In frontend JS, everything should be a dev dependency. At runtime, you only use the JS bundles generated by your bundler, which is a build-time process. That means you don’t actually directly use Node modules at runtime, just the bundled versions, so there should not be any non-dev dependencies.
For backend JS, anything only used in dev (unit testing, mocking, bundlers, etc) should be a dev dependency, and stuff you need at runtime (like Express, etc) should be a regular dependency.
I don’t think it’s accurate to say that for frontend, everything should be a devDependency. It’s more a matter of personal taste what goes where. I’ve had good experiences with using devDependencies for anything that doesn’t end up in the bundle, and everything else as a normal dependency. That seems more useful than having everything in one category.
Sure, that’s fine. I think I didn’t word my comment well. What I meant to say was that you only ever do dev installs for frontend apps, so there’s no difference between dev dependencies and regular dependencies. You can split things however you want.
If you’re bundling code, you’re doing development work, and you’d have devDependencies installed:
For a library, once you’ve shipped your code, someone using it wouldn’t need your bundler/testing libraries/dependency types/compilers/etc installed, so they wouldn’t install your devDependencies.
For an application, if you’re building it on the server, you’re probably doing it wrong, but in that case you would want to install devDependencies. If you’ve built it locally or in a pipeline and you’re running it on the server from your artifact, then you probably don’t need devDependencies, as those are only useful during dev and build.
Good points. I never build libraries, only websites, so it didn’t really occur to me that the dependency types we’re mostly intended for that use case.
I use a pipeline to build and right now there’s one stage that just installs everything, then I have separate build and test jobs. The two main issues I’m trying to correct are the fact that npm takes ages to install dependencies (even with npm ci) and that I’m subject to security scans and I don’t want to be held up because of a vulnerability in my testing tools.
I think it makes more sense if you think about backend applications: If you write a Webserver with ExpressJS in typescript, you need typescript only to compile it (dev dependency) but once compiled, you only need ExpressJS in your node_modules for the app to be able to run (“regular” dependency).
Frontend development is a bit strange in that respect, because often everything gets bundled into your dist/ directory, so technically there are no runtime dependencies? In that case it’s more of a hint to let you know “this goes into the bundle” vs. “this is part of the compiler toolchain”
For frontend I use the dev dependencies for testing tools. Ex. Cypress. That way my build pipeline doesn’t need to download a bunch of things that won’t be used.
It should be what you need to run it in production, so most frontends really only should declare dev dependencies.
Take jQuery for example: all dev dependencies. They ship a bundle, so all of the libraries and tooling they use, you don’t care.
If your frontend ever becomes a dependency of a bigger thing, or gets imported by the server as a dependency for your UI, you also don’t need to download all of your runtime dependencies you bundled together, you really only need the bundle.
javascript
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.