anti: Referencing assets inside js files to integrate them
export {default as icon} from './src/styles/logo-blue-32x32.png';
import './src/styles/logo-blue.scss';
correct: Referencing them as string inside your app later central in your build tool or deploy chain resolve the asset references if needed most best is to even optain the asset references from a central file or api depending on the app size. As Rule never process your assets when you process your development code.
anti: scripts in package.json correct: always create indipendent scripts as js even if you execute shell code that makes it more easy to integrate your project into bigger once. you can call them from package.json if needed for migration
anti: put packageing scripts into the project correct: put them into a indipendent package if they are needed or indipendent modules and scripts in a seperated folder. for npm packages always create mono repos with the packages/ and put in the root a package.json that references the packages as workspaces in large projects create workspaces/ with indipendent package.json files that contain workspaces. referencing a flat packages/ folder.
anti: do not use webpackage or rollup plugins that bundle assets into the source code some how assets should be indipendent external referenced there are rare case where exemptions exist like service workers and other workers but never for applications or shared application assets.
anti: reference packages by version correct: reference by registry and tag inside package.json eg: npm:package-name@latest together with the time stemps inside package.json or the package-lock.json the correct version can get found that was the last known working. The package.json if it gets used should always reference latest to auto update the packages.
anti: dev never with something that needs additional processing corrrect: create dev bundels or packages that contain builded assets to work with.
anti: do not use .css files correct: apply your style from reuseable imported style.js files and apply them on the elements on creation. do so via Object apply or attaching a style element to your element root. depending on your usecase. on large scale projects you can do .css parsing for migration and then MutationObserver + querySelectorAll gets you covered.