We Keep Coding

How do I import Pixi.js into a TypeScript project?

I'm new to Pixi.js but I have some past experience with TypeScript. I'm really struggling to import Pixi.js into my project.
I got a small Pixi.js project running using a CDN import of Pixi and vanilla JavaScript, and now I'm trying to get that same project running on TypeScript. I think one of my options would be to use the CDN import of Pixi and then import the type definitions for Pixi, but I read in several places that the later versions of Pixi are already written in TypeScript, so I don't think it's a good option for me to use a JavaScript version of the library and then import my own TypeScript definitions.
I tried using npm install pixi.js and then import * as PIXI from "pixi.js"; but that gives me this TypeScript error:
This module is declared with using 'export =', and can only be used with a default import when using the 'allowSyntheticDefaultImports' flag.
and it also gives me this browser error when I force it to compile anyway:
Uncaught TypeError: Failed to resolve module specifier "pixi.js". Relative references must start with either "/", "./", or "../".
This error makes sense to me, because clearly telling the browser to find pixi.js will result in no file being found, since it's a Node.js module.
I tried changing import * as PIXI from "pixi.js"; to import PIXI from "pixi.js"; to get rid of the "only use default import" error, but that just gives me a "pixi.js has no default export" error, which seems to be in direct contrast with the error I was getting before, saying that it only has a default export...
And even if I manage to get rid of the TypeScript errors, I still can't wrap my head around how this would function properly anyway since the browser has no idea what "pixi.js" is when it's referring to a Node module that doesn't even exist inside the browser...
So all of this leads me to my question of how do I get a Pixi.js program running with TypeScript? I've looked up tutorials many times but every single one includes something like Webpack, Browserify, etc. I would not like to use any bundlers/other dependencies at all, I simply want to write TypeScript code, compile it, and have it give me some .js files that I can pop directly into a .html file and run in my browser. Is this possible?
My findings thus far have been that what I'm looking for is (somehow) not possible. I've found that my options are either to import the vanilla JavaScript version of Pixi and just go without type information (and do some hacky workarounds to get TypeScript to not think PIXI is undefined), or use a bundler like Webpack. Neither of those are ideal, and I have to think there's another option...

It would depend on your setup, but you could try something like this:
import { Sprite } from '#pixi/sprite';
new Sprite()
or you could try importing all as PIXI like this
import * as PIXI from 'pixi.js';
new PIXI.Sprite()

You must have figured this out but still I want this answer to be here for other to see.
This is my demo project on github that you can clone and use. It has typescript and pixi.js installed. THIS PROJECT USES VITE instead of webpack which is very complicated.
pxts :pixi.js setup library
Some of things you must keep in mind
Pixi.js version 6 has typescript types bundled along.
Most of the examples on line are old and out of date
Latest pixi version is v 7.x for which there is no community support yet.
link for version 6.5.8 docs
While working with version 6.x you have to install Assets separately where as in Version 7.x its bundled in.
OLD AND OUT OF DATE TUTORIALS ONLINE is the main reason for confusion. Do check which version you have got installed.

The 'correct' way to share code across TypeScript, nodejs and JavaScript

I want to have a mono repo that contains the following:
shared: a bunch of TypeScript classes that can be used ANYWHERE
WebClient: a react web app in JavaScript (that needs to use code in shared)
WebServer: a TypeScript server app for the react app (that also needs to use shared code)
The key issue is: how to I define, configure and access the shared code?
I'm totally lost, I've tried a hundred different approaches and nothing works. Any help would be appreciated.
NOTE: appreciate any comments, but please explain like I'm 5! A mini GitHub repo with 3 HelloWorld projects would be great!

Install Lerna and use it to manage the shared classes as packages. Read the documentation and don't be afraid to experiment with it.
If you want to see a Github repo that makes use of Lerna, there are quite a few, one of which is Facebook's Jest.
https://github.com/facebook/jest

Vue website complains that JavaScript isn't enabled after Vuetify is added

So this is abit of a tough one for me as this is a new learning curve and I'm not entirely sure how to debug it.
I'm following a tutorial listed Here but I made to to where we add navigation to the main page and started up the app to see how it looks and noticed a blank page. I copied the tutorial code eventually and double checked my javascript settings and ensured it is on. I started a new project and it worked fine showing the base template but after adding Vuetify, the page turned blank with
We're sorry but meal-prep doesn't work properly without
JavaScript enabled. Please enable it to continue.
in the console.
I know questions like this are not allowed but I'm not quite sure what else to look for.
If someone could point me in the right position or needs to see any specific file, ill add it.
Thanks
Going in order of #skirtle questions,
I created the project by using vue create in my terminal.
I started the app after that and it showed the default Vue home page. I then stopped the server then installed Vuetify by using vue add vuetify. After this however is when my problem starts. I started up the app again and the default vue home page is just a blank page and the html in the dev console is as follows.
There were no changes made besides installing this plugin.
My versions are as follows
Vue - vue#2.6.10
Vue CLI - #vue/cli 4.0.5
Vuetify - vuetify#2.1.6
I'm getting a warning in my VSCode terminal, which states
warning in ./src/plugins/vuetify.js
"export 'default' (imported as 'Vuetify') was not found in 'vuetify'
And in my web console
Uncaught TypeError: Cannot read property 'extend' of undefined
at Module.srcMixinsThemeableIndexTs (vuetify.js?ce5b:33332)
at webpack_require (vuetify.js?ce5b:30)
at Module.srcComponentsVAppVAppTs (vuetify.js?ce5b:380)
at webpack_require (vuetify.js?ce5b:30)
at Module.srcComponentsVAppIndexTs (vuetify.js?ce5b:465)
at webpack_require (vuetify.js?ce5b:30)
at Module.srcComponentsIndexTs (vuetify.js?ce5b:28810)
at webpack_require (vuetify.js?ce5b:30)
at Module.srcIndexTs (vuetify.js?ce5b:30337)
at webpack_require (vuetify.js?ce5b:30)
I hope this gives a better insight to my problem.

I was able to reproduce the same problem with Vue CLI 3.8.4.
It would seem that you're running into an incompatible combination of options. I don't exactly know where the fault lies but the tutorial you are using encourages a lot of custom configuration options, which makes it more likely you'll fall through a crack. It also makes it much more difficult to give an answer as the answer to some extent depends on exactly what combination of options you choose.
Nevertheless there does seem to be a bug somewhere here, though I'm unclear exactly which bit it buggy. My guess would be the Vuetify CLI plugin.
This bug report seems somewhat related:
https://github.com/vuetifyjs/vuetify/issues/9184
The simplest way to fix it seemed to be to edit the file vue.config.js and remove the line:
transpileDependencies: ["vuetify"]
However, that's no good if you actually do want to transpile Vuetify.
This is where it gets really complicated and it depends a lot on exactly what settings you want.
In the file src/plugins/vuetify.js you should find two lines like this:
import Vuetify from "vuetify";
import "vuetify/dist/vuetify.min.css";
That won't work with transpiling.
There are a few possible ways to go here but try changing them to:
import Vuetify from "vuetify/lib";
If you start the server you may see another error:
Failed to resolve loader: sass-loader
You may need to install it.
There are some instructions for how to solve that problem in the Vuetify installation guide:
https://vuetifyjs.com/en/getting-started/quick-start#webpack-installation
However, rather than trying to do all of this manually, you will likely find it easier to go back to the CLI and create a project with a different combination of options. Without spending hours and hours trying all the different permutations I can't say for sure exactly what does and doesn't work but from a quick experiment it seemed that enabling CSS Pre-processors during the project creation makes the sass-loader error go away.

It happened the same to me and I realized that I had only download it in the CLI complements but forgot to add it.
To do so write in the terminal:
vue add vuetify

How to find dead code in a large react project?

In order to refactor a client-side project, i'm looking for a safe way to find (and delete) unused code.
What tools do you use to find unused/dead code in large react projects? Our product has been in development for some years, and it is getting very hard to manually detect code that is no longer in use. We do however try to delete as much unused code as possible.
Suggestions for general strategies/techniques (other than specific tools) are also appreciated.
Thank you

Solution:
For node projects, run the following command in your project root:
npx unimported
If you're using flow type annotations, you need to add the --flow flag:
npx unimported --flow
Source & docs: https://github.com/smeijer/unimported
Outcome:
Background
Just like the other answers, I've tried a lot of different libraries but never had real success.
I needed to find entire files that aren't being used. Not just functions or variables. For that, I already have my linter.
I've tried deadfile, unrequired, trucker, but all without success.
After searching for over a year, there was one thing left to do. Write something myself.
unimported starts at your entry point, and follows all your import/require statements. All code files that exist in your source folder, that aren't imported, are being reported.
Note, at this moment it only scans for source files. Not for images or other assets. As those are often "imported" in other ways (through tags or via css).
Also, it will have false positives. For example; sometimes we write scripts that are meant to simplify our development process, such as build steps. Those aren't directly imported.
Also, sometimes we install peer dependencies and our code doesn't directly import those. Those will be reported.
But for me, unimported is already very useful. I've removed a dozen of files from my projects. So it's definitely worth a shot.
If you have any troubles with it, please let me know. Trough github issues, or contact me on twitter: https://twitter.com/meijer_s

Solution for Webpack: UnusedWebpackPlugin
I work on a big front-end React project (1100+ js files) and stumbled upon the same problem: how to find out which files are unused anymore?
I've tested the next tools so far:
findead
deadfile
unrequired
None of them really worked. One of the reason is that we use "not standard" imports. In additional to the regular relative paths in our imports we also use paths resolved by the webpack resolve feature which basically allows us to use neat import 'pages/something' rather than cumbersome import '../../../pages/something'.
UnusedWebpackPlugin
So here is the solution I've finally come across thanks to Liam O'Boyle (elyobo) #GitHub:
https://github.com/MatthieuLemoine/unused-webpack-plugin
It's a webpack plugin so it's gonna work only if your bundler is webpack.
I personaly find it good that you don't need to run it separately but instead it's built into your building process throwing warnings when something is not ok.
Our research topic: https://github.com/spencermountain/unrequired/issues/6

Libraries such as unrequired and deadcode only support legacy code.
In order to find the unused assets, to remove manually, you can use deadfile
library:https://m-izadmehr.github.io/deadfile/
Out of box support for ES5, ES6, React, Vue, ESM, CommonJs.
It supports import/require and even dynamic import.
It can simply find unused files, in any JS project.
Without any config, it supports ES6, React, JSX, and Vue files:

First of all, very good question, in large project coders usually try many lines of code test and at the end of result, hard to find the unused code.
There is two possible that must be work for you - i usually do whenever i need to remove and reduce the unused code into my project.
1st way WebStorm IDE:
If you're using the web-storm IDE for JS development or React JS / React Native or Vue js etc it's tell us and indicate us alote of mention with different color or red warning as unused code inside the editor
but it's not works in your particular scenario there is another way to remove the unused code .
2nd Way unrequired Library: (JSX is not supported)
The second way to remove the unused code inside the project is unrequired library you can visit here : unrequired github
another library called depcheck under NPM & github here
Just follow their appropriate method - how to use them you will fix this unused issue easily
Hopefully that helps you

I think the easiest solution for a create-react-app bootstrapped application is to use ESLint. Tried using various webpack plugins, but ran into out of memory issues with each plugin.
Use the no-unused-modules which is now a part of eslint-plugin-import.
After setting up eslint, installing eslint-plugin-import, add the following to the rules:
"rules: {
...otherRules,
"import/no-unused-modules": [1, {"unusedExports": true}]
}

My approach is an intensive use of ESlint and make it run both on IDE ad before every push.
It points out unused variables, methods, imports and so on.
Webpack (which has too nice plugins for dead code detection) take care about avoiding to bundle unimported code.

findead
With findead you can find all unused components in your project. Just install and run:
Install
npm i -g findead
Usage
findead /path/to/search

This question recalls me that react by default removes the deadcode from the src when you run the build command.
Notes:
you need to run build command only when you want to ship your app to production.

Using Nodejs with Typescript

I would like to use Nodejs in my typescript project and downloaded node.d.ts from https://github.com/borisyankov/DefinitelyTyped/tree/master/node
But VisualStudio finds a lot of errors in the .d.ts file. They're all basically the same:
Error 2 exported interface 'Server' extends interface from private
module 'events' C:\Users\lhk\Desktop\typescript-game\strategy
go\node\node-0.8.d.ts 236 37 node-0.8.d.ts
All the error messages complain that a private interface is extended.
I searched SO and found this question:
nodejs require inside TypeScript file
One of the comments gives the advice to download node.d.ts from the Microsoft samples. I browsed the internet, found this article http://stackful.io/blog/typescript-nodejs-vim-and-linux-oh-my/ and downloaded the second version of node.d.ts , with the exact same result.
Where do I find a proper definitions file for nodejs and Typescript ?

For the 0.8.1-1 version of TypeScript, use the latest node.d.ts file from this github project:
https://github.com/soywiz/typescript-node-definitions
I was getting the same exported interface errors until I pulled the latest definition files from there.

I'm not entirely sure what the heck is going on here.
I suspect that the current version of the (0.8.1~1) node.js package for Typescript broke some stuff. I've been running into this too. I tweaked the node.d.ts file and marked a couple things "export" instead of "declare" and that got me past my compilation issues, but I'm finding that the functions are not showing up in the current scope.
FWIW, I have been playing around with a personal fork of typescript-require and typescript-wrapper (both of which required some tweaking to work with 0.8.1~1) and I'm wasn't too certain that everything is working as well as it should be, so I wasn't sure that the issue is my issue or something endemic to the current node/typescript.