Closed ajmeese7 closed 2 years ago
But I have not had a chance to set up a local OS.js env and test yet.
It's a shame that linking meta packages like this basically doesn't work in npm anymore :(
A hacky workaround is to just copy the dev-meta
local source into node_modules
when you need it for stuff like this.
Some package managers allow for this in a monorepo setup though, but linking is a no-go.
I assume that with this package, importing will be something along the lines of:
Indeed.
Seems like you accidentally included a package-lock update here. Revert this. Also the .gitignore really should be a separate commit (or a separate PR).
The package-lock.json
was actually intentional, since the lock file is currently out of date as compared to the package.json
. But no problem, both changes can be removed and added in a separate PR.
It's a shame that linking meta packages like this basically doesn't work in npm anymore :(
100% agreed, that's the main reason I transitioned to rush
for my monorepo in the first place, because it was so impossible to locally test all dev-meta
updates. I got frustrated trying to update to Webpack 5 since it is currently so difficult to configure.
The package-lock.json was actually intentional, since the lock file is currently out of date as compared to the package.json.
This is actually perfectly fine. It's only metadata that is not in sync. This file is not included for distributed packages, nor does it have any impact on local development (git checkouts) :)
Yep, just checking out my Codespaces automatically made the account and the .gitignore
since that's part of their setup process, so I figured it wouldn't hurt to push the change. I often forget that other people organize their commits a lot more, I usually push all the working code that I have changed even if it is not specifically related to the purpose of the commit.
Slowly working on it though :)
I often forget that other people organize their commits a lot more
I touch on this quite a lot because of the following benefits:
I use https://www.conventionalcommits.org/en/v1.0.0/ pretty much in all projects nowadays, but never adapted that in this one because it was started way before I knew about that. But I'm considering enforcing that as well. So easy to automate semver and changelogs that way. And it also goes into the whole thinking about stuff in smaller chunks.
If you're interested, I have also modified my instance to alphabetize the icon names and filter out .map
and .js
file types, for a cleaner end result. The order is not always the same for the assets, so sorting them by name ensures that there are no arbitrary metadata file changes without any updates to the underlying content. And we are obviously not interested in those non-icon file types in the metadata, so I removed the only instances of such that I have encountered, which are .map
and .js
files.
filter out .map and .js file types, for a cleaner end result.
Ideally this implementation should pick only the icons.
no arbitrary metadata file changes without any updates to the underlying content
There's a handy term for this: Idempotence ! I think this should be implemented as well.
Thanks!
Squashed and re-worded commit for more context
Published with 2.3.0
This is intended to update the metadata of a package to include the icon file types, allowing for a mix-and-match of
svg
,png
,gif
, etc.This has not been tested in a
dev-meta
context, but when it is included in a local repo, the usage is as follows:I assume that with this package, importing will be something along the lines of:
But I have not had a chance to set up a local OS.js env and test yet.
Related to https://github.com/os-js/osjs-client/pull/191.