Develop Reference

No errors present => ReactDOM.render() method nowhere to be found

I'm trying to learn more about React.js from the ground up.
While reading the documentation I found that using ReactDOM.render(element, Document.getElementById("root")) would pass the JSX referenced by the word element to the element with id="root" in an HTML file. This shows what I mean.
When I looked through my repo created with the command npx create-next-app --example with-tailwindcss <app-name> I noticed that not only is there no ReactDOM.render() method being used anywhere in the file structure, but there is also no HTML file anywhere in the repo and all of the data seems to flow into index.js which returns the final JSX elements, but I can't find where that Home function is called as <Home /> anywhere.
Is there an HTML file hidden somewhere that I'm missing or is there some sort of more advanced level coding at play here that picks up the return from the Home function and does the ReactDom.render() functionality some other way? Maybe like in binary or with transpiling or something? I'd really appreciate some documentation that explains this in detail with examples.

This repo is powered by NextJs, so yes - there is an extra level on top of React, looking for any React component in pages/index.js to render the root, by naming conventions of framework, there are few places mentioning this in docs

Vue3 documentation example codeblocks are strange

All throughout the Vue 3's documentation, they do the following when showing example code in a component:
Vue.createApp({})
I've never had to do this though, I simply use
<script>
export default {
name: 'example-component-xd'
}
</script>
What am I missing here? I just started learning Vue 3, and I haven't learnt any other versions of Vue before. This question is more just a curiosity I have, as it doesn't impact my ability to understand the documentation, but I thought that it may have something to do with the history of Vue, ES6 or best practices etc. Here is another example:

In Vue 3, Vue.createApp({}) replaces new Vue({}) from Vue 2. This line of code is typically in your entry file, where you mount the app (not in your component files).
The code in the <script> tag you showed is for single file components, and you can continue using that style. Never would you use Vue.createApp() or new Vue() in those single file components.
You can checkout an example Vue 3 app that shows Vue.createApp() in src/main.js, while the single file components in src/components use the Options API that you're also using.

Import gives undefined in Typeorm

I am a newbie at using typeorm. The project that I am working on I created all entities. Then, I wanted to make imports cleaner. The code crashes due to the fact that I made it imports like the below example.
I export the files from 'entities/index.ts'
import Account from './Account';
import Order from './Order';
export {
Account,
Order,
};
Thus, I can import all entities once.
import { Account, Order } from '#entities/index'
PS: The above example is a dummy in order to show the case.
The problem is that I faced. When I run the application it shows me undefined. I tried to direct import like
import Account from '#entities/Account';
Then it works. But I don't want to make like that. If I do like that, the imports will look bad.
You can see below in the example how I debug it. (BaseEntity gives undefined)
User.ts
BaseEntity.ts
entities/index.ts
Result
Thanks for your contribution.

The problem seems to be a javascript circular dependency, rather than a TypeORM problem. This article seems to get at the core problem of dependency load order when there is a cyclic dependency. Circular Dependency Issues So the load order might be Account, BaseEntity, User and User has not fully loaded by the time Account needs it.

javascript one class per file using eslint

I would like to use javascript classes with one class per file. It is part of a larger project using eslint. I started with:
/*global CSReport*/
/*global CSManager*/
class CSMain {
constructor() {
this.report = new CSReport();
this.manager = new CSManager(this.report);
}
launchReport(...
}
However, eslint generates an error saying CSMain is defined but never used. This led to the idea of using export and import which seemed better than making everything global (side note: CS in front of main is the old style method to avoid global conflicts)
The question is how to put this together. The release version will be a single (uglified) file, so the class file names will no longer exist when they are all concatenated together in (say) csCompiled.js.
Questions:
Import uses a file name. Should I use the CSCompiled.js name rather than the file names before concatenation?
Do I want a single module or a module for each class?
Do I need to export every class and import every class it uses?
I am not fully sure how angular accesses this code but am thinking to import csMain.
I tried to find an answer to this but am only finding older posts that don't use ecmascript 6 and classes. If an answer to this exists, I am not sure how to get to it.
Background:
The main project uses angular 1. This code is separate for legacy reasons. It is currently written in java using gwt, but we want to move to javascript to remove the reliance on gwt. It is about 30-40 files (classes) total to convert.
The code gets and handles data from the server for report requests. There is a lot of pre-processing done before it is handed back to the rest of the UI.
I have used javascript for an established project using angular, but lack expertise on how to create new projects.
I am trying to use basic javascript for this, so it won't need updating if (for example) we go from angular 1 to the current versions. I do not yet know if this is a good way to do it.

ESLint is complaining because you are not exporting the class you created, therefore, it can't be accessed by other modules. You can fix that with a simple line at the end
export default CSMain;
Import uses a file name. Should I use the CSCompiled.js name rather
than the file names before concatenation?
Use the file name before you compile/transpile/uglify/etc. After that it will all become 1 file and the bundler will take care of that for you.
Do I want a single module or a module for each class?
Completely optional, I like to have 1 class per file and then 1 file for the module (index.js) that lists all classes in that module.
Do I need to export every class and import every class it uses?
Yes, you need to import everything your module will use and export everything that should be public or "importable" for other modules.
I am not fully sure how angular accesses this code but am thinking to import csMain.
It all depends on how you export your file. Make sure to import the same name your module/file is exporting.

Why are package imports needed in Meteor

About a year ago I have used Meteor, and now I want to use it again, but many things have changed.
When I follow the Blaze tutorial on Meteor.com, they add imports on top of their files:
import { Meteor } from 'meteor/meteor';
import { Template } from 'meteor/templating';
import { ReactiveDict } from 'meteor/reactive-dict';
I got the app working. But when I comment the imports out, the app keeps working like it should work. Why are these imports needed?
I am still using the regular Javascript, not ES6.
Thanks!

The import statement is used to import functions, objects or primitives that have been exported from an external module, another script, etc.
The name parameter is the name of the object that will receive the exported members. The member parameters specify individual members, while the name parameter imports all of them. name may also be a function if the module exports a single default parameter rather than a series of members. Below are examples to clarify the syntax.
Import an entire module's contents. This inserts myModule into the current scope, containing all the exported bindings from "my-module.js".
For more detail about the different ways we can use import along with their usage, please check this.

They still use the old globals for backwards compatibility. However it is recommended to use the imports so if in some future release they remove the globals your code will still work. You can read more in the appropriate section of the guide.

Ok you know import is to import an exported object from another file already.
The point that you may have missed is that MDG heard the need to stop loading everything by default, or at least to provide a mean to control what is loaded in memory and what is not.
Look for the /imports special directory.
Files in that folder are no longer loaded automatically, but only through import statement.
As for the tutorial, I guess they did not explained this functionality, and because it imports only standard functionalities which are still loaded eagerly for backward compatibility, it does not change anything removing those statements.