Question: Unable to resolve module when using path alias in environment with ESModule and TypeScript?

The whole idea of TypeScript is to add static types on top of JavaScript, not to be a higher-level language that builds to JS. The C# / IL comparison is not apt at all.

There's literally no line of undownleveled JavaScript code you can write where TS intercepts some *string* in it and changes it to be something else. This is 100% consistent with TS behavior in every other kind of JS construct; it would be frankly bizarre to have import paths be the one thing that we decide to go mess with.

Unable to resolve module when using path alias in environment with ESModule and TypeScript
Hello! First of all, thank you for your wonderful project. I'm having some problems using this template, so if you know where I can find a solution, could you please let me know?

In an environment using TypeScript and ESModule, importing using the path alias set on `tsconfig.json` gives the following error and does not work properly.

/home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/dist-raw/node-internal-modules-esm-resolve.js:757
 throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base));
 ^
Error: Cannot find package '~' imported from /home/yupix/works/remix-v2-server/build/index.js
 at packageResolve (/home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/dist-raw/node-internal-modules-esm-resolve.js:757:9)
 at moduleResolve (/home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/dist-raw/node-internal-modules-esm-resolve.js:798:18)
 at Object.defaultResolve (/home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/dist-raw/node-internal-modules-esm-resolve.js:912:11)
 at /home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/src/esm.ts:218:35
 at entrypointFallback (/home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/src/esm.ts:168:34)
 at /home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/src/esm.ts:217:14
 at addShortCircuitFlag (/home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/src/esm.ts:409:21)
 at resolve (/home/yupix/works/remix-v2-server/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.3.63_@types+node@20.8.4_typescript@5.0.4/node_modules/ts-node/src/esm.ts:197:12)
 at nextResolve (node:internal/modules/esm/hooks:833:28)
 at Hooks.resolve (node:internal/modules/esm/hooks:278:30)
Failed running './server.ts'

### Projects I have tested

 URL

### Environment

OS: Ubuntu 22.04.3
Remix: v2.0.1
pnpm: v8.6.7
node: v20.8.0

Hi there, there appears to be a bug with the latest version of @swc/core that caused the error. For now, please fix your @swc/core to 1.3.82:

In package.json:

` "@swc/core": "1.3.82",`

I'll dig further into this over the weekend, sorry for the hiccup!

Thanks for your quick reply. I changed `@swc/core` to `1.3.82` and still get the same error. I have also updated the repositories I am testing. I'll be waiting for the weekend.

Try deleting your pnpm-lock and run `pnpm install; pnpm run dev` again.

I deleted `pnpm-lock.yaml` and ran `pnpm i`, but it does not seem to change. Also, I forgot to commit `pnpm-lock.yaml` to the repository, so I committed it.

That's really strange. I am testing on Windows and Mac environment, so I wonder if there's something specific with swc's Linux kernel that's broken. You can try an older version like 1.3.78 and see if that get it working again.

I'll look into migrating the template to `tsx` instead of `ts-node`, hopefully that would sidestep this issue altogether. Sorry for the trouble!

After changing to `1.3.78`, I removed the lock and reinstalled using the same procedure as before, but the error does not seem to change.

I have also checked the operation on Windows, but the error seems to occur in the same way as with Linux.

### How to reproduce

git clone URL
git checkout esm-server.ts

pnpm i
pnpm dev
pnpm dev

### Environment

OS: Windows 11 Pro 22621.2361
pnpm: v8.8.0
node: v20.8.0

I have started working the switch to tsx, you can observe the progress on this branch:

 URL

Feel free to test it out and let me know if it works for you!

I think it is very cool to tsx, but the error still seems to be the same. Do you get any errors with imports like `import { say_hello } from "~utils/hello.js"` in your environment?

Also, importing using relative paths works fine, but the paths that can be set on tsconfig do not seem to be resolving properly.

Yes, aliasing works just fine in my environment:

image

I'm quite confused and having trouble nailing down what might be causing all these issues for you.

* Does the default template `npx create-remix` have the same issues for you?
* What about the Epic-Stack? URL

<img width="651" alt="image" src=" URL
<img width="237" alt="image" src=" URL

Thank you for your reply. I just wanted to let you know that I noticed that if you do not give the extension (.js) when importing, an error is displayed on the editor, but Remix works fine without error.

As far as I know, when using ES Module in TypeScript, the import must specify the extension `js`, is this wrong?

 URL

You're correct. ESM requires the extension. I was working on the wrong branch when testing above, import { Hello } from "~/utils/hello.js"` is the right syntax.

I have found that by setting the extension to `.ts` instead of `.js`, there are no errors on the editor, and the remix seems to work correctly. I see that the epic stack you mentioned also specifies `.ts`. Is it common to specify `.ts` instead of `.js`?

.js should work as long as you have `allowJs": true` in tsconfig.

You are certainly right about the use of different extensions. This time, hello.ts only provides a function `say_hello` to output `Hello World` using console.log, so I used `ts`. I'm going to close this Issue for now, since it seems that specifying the extension as it is will solve the problem. Thank you for your time. Have a nice weekend!

Compiled JavaScript import is missing file extension
**TypeScript Version:** 4.0.3
**Search Terms:** module es6 es2015 import file extension missing js ts bug 404

**Steps to reproduce:**

Create a `main.ts`:

ts
import {foo} from './dep';
console.log(s, foo);

Create a `dep.ts`:

ts
export const foo = 42;

Create a `tsconfig.json`:

json
{
 "compilerOptions": {
 "module": "ES2015"
 }
}

Then run:

shell
npx tsc

**Expected behavior:**

The compiler generates JavaScript "which runs anywhere JavaScript runs: In a browser, on Node.JS or in your apps" (according to the TypeScript homepage). For example, it would be valid to create two files as follows; `main.js`:

js
import { foo } from './dep.js';
var s = "hello world!";
console.log(s, foo);

And `dep.js`:

js
export var foo = 42;

(More generally, the expected behavior is that the module specifier in the generated `import` must match the filename chosen for the generated dependency. For example, it would also be valid for the compiler to generate a file `dep.xyz`, if it also generated `import ( foo } from './dep.xyz'`.)

**Actual behavior:**

As above, except that in `main.js`, the `import` URL does not match the filename chosen by the compiler for the generated dependency; it is missing the file extension:

js
import { foo } from './dep';

When executing `main.js` in the browser, it requests the URL `./dep`, which is a 404. This is expected, as the correct relative URL would be `./dep.js`.

**Related Issues:** URL voluntarily closed by the reporter for unknown reasons

TypeScript doesn't modify import paths as part of compilation - you should always write the path you want to appear in the emitted JS, and configure the project as necessary to make those paths resolve the way you want during compilation

Thanks @RyanCavanaugh! Do you mean I should write `import { foo } from './dep.js'` in my source `main.ts`? That does actually seem to work! In that the compiler uses `'./dep.ts'` to find the types of variables exported.

However, I find this surprising, because

- The recommendation everywhere else in TypeScript docs is to omit the file extension.
- If I try to import from `'./dep.ts'`, the compiler gives me `error TS2691: An import path cannot end with a '.ts' extension. Consider importing './dep' instead`. So apparently it's not possible to generate JavaScript imports that end in `.ts`?
- The module resolution docs don't say what's going on here. What logic makes this work? Is there a special case for `.js`, which is mapped to `.ts`?
- I can't find a rationale for this design anywhere.

TS never takes an existing valid JS construct and emits something different, so this is just the default behavior for all JS you could write. Module resolution tries to make all of this work "like you would expect"

See also URL

@RyanCavanaugh that principle makes sense. My remaining confusion then is why the docs and compiler encourage omitting the file extension, if "you should write the import path that works at runtime". Maybe this encouragement is designed for a JS runtime that demands that you omit the file extension. But the runtimes I'm aware of are browser, ES modules, and Node.js, none of which make this demand.

@RyanCavanaugh Writing "./dep.js" doesn't sound logical. It requires the coder to know the exact complied output and be fully aware of the compiled environment. Isn't the whole idea of Typescript to abstract Javascript?

`import { foo } from "./dep"` is legitimate Typescript, and it provides the information for Typescript to resolve all that is needed to make the code compiled successfully. So, the compiled output similarly has to work.

problem is, ts does not only need to add '.js', there are complexer resolution strategies.

i would like it, if there would be a way of calling a plugin after transpilation had been done, so I could fix the import names with that.
I know I could use a bundler / build system, but we ship directly the code typescript generates, without an additional build step. at the moment we fix the import path's in our own webserver.

@RyanCavanaugh @jameshfisher I was about to post a new bug about TypeScript but then the template encouraged me to search again, and I found this issue, which might be similar enough.

But I'm still confused, even reading above.

Here is the "bug" I submitted to the "vscode" repo, and that team rejected it and said that I should submit to the "TypeScript" repo here: URL

It seems that people trying to write TypeScript in VSC face this dilemma of choosing between:

1. VSC shows an error (red underline), but the code works, or:
1. If we follow the VSC error tooltip's suggestion, it will "resolve" the error in the editor, but then the code won't run.

image

I'm getting this error and don't understand why:

 An import path cannot end with a '.ts' extension. Consider importing '_______' instead. ts(2691)

See also: microsoft/TypeScript#11235 (comment)

So far, I have had success with @RyanCavanaugh's suggestion to "always write the path you want to appear in the emitted JS, and configure the project as necessary to make those paths resolve the way you want during compilation".

But I am still confused because this advice contradicts the compiler and docs and ecosystem, which all encourage omitting file extensions.

Yeah that doesn't feel right. I really don't understand. I can't think of any principle where it would make sense to throw a prominent red error for something legal.

Same issue here. Adding a `.js` in the import inside a TypeScript file does allow to compile it with the TypeScript compiler and will output files with working ESM imports.

However, when I add `.js` extensions on the imports, I can't get testing working. Tried with Mocha and Jest, but no luck so far: they complain the files with `.js` extension don't exist, which is correct, those files don't exist since they actually have a `.ts` extension.

I would love to see the TypeScript compiler add `.js` extenstions on imports when the output is esm/es2015.

The problem I'm running into is that I need the `.js` extension added to `export` statements, not just `import`. I have this `index.ts` file for a library of math functions:

export * from './math.js';
export {
 Angle, convertFromRadians, convertToRadians, FMT_DD, FMT_DDD, FMT_HH, FMT_MINS, FMT_SECS, FMT_SIGNED,
 HALF_PI, Mode, PI, TWO_PI, Unit
} from './angle.js';
export { MinMaxFinder } from './min-max-finder.js';
export { SphericalPosition } from './spherical-position.js';
export { SphericalPosition3D } from './spherical-position-3d.js';
export { ZeroFinder } from './zero-finder.js';

Adding `.js` only works for the first line. I don't know if that's because it's a wildcard export or not. But the generated JavaScript code is missing the `.js` everywhere else:

export * from './math.js';
export { Angle, convertFromRadians, convertToRadians, FMT_DD, FMT_DDD, FMT_HH, FMT_MINS, FMT_SECS, FMT_SIGNED, HALF_PI, Mode, PI, TWO_PI, Unit } from './angle';
export { MinMaxFinder } from './min-max-finder';
export { SphericalPosition } from './spherical-position';
export { SphericalPosition3D } from './spherical-position-3d';
export { ZeroFinder } from './zero-finder';
//# sourceMappingURL=index.js.map

@josdejong you can get around this by using an `index.ts` file. In the index.ts file do the following `export { MyClass } from 'src/my-class.js'`, and in your test just import the file directly instead of via the index file `import { MyClass } from `src/my-class.ts`.

Thanks for sharing your workaround @bobbyg603 . I'm not sure how that would work for the imports inside `src/my-class.ts`, (nested). You can't change that dynamically depending on your context (testing or actually using).

It feels to me like there is a serious mismatch between plain ES modules (requiring actual existing paths with proper file extensions) and TypeScript code (relying on "smart" nodejs module resolution, not requiring file extensions, and (implicitly) changing the (implicit) file extensions from .ts to .js when compiling). I can't understand this issue is marked "Working as intended" in URL this is a problem that needs to be addressed.

Most logical to me would be to write imports with `*.ts` extension in your code (matching the actual file extension). And when compiling, have TypeScript replace `*.ts` extensions with `*.js`, matching the actual file extension of the compiled file (which is changed to `*.js` by TypeScript). TypeScript changes the file extensions from `*.ts` to `*.js`, so logically it should also fix corresponding imports.

Facing the same problem.

In most scenarios, we use webpack. But for simple scenarios and samples, e.g. for our TS-training for developers, we want to use plain TS files and JS modules without the complexity of another transpiler like Babel/webpack.
It looks odd in training classes when you try to explain the beauty of TS and then have to stutter something like "TS never changes outputted strings". Or you have to tell them that it will get better with webpack.
=> "The simple case is ugly but it looks good in the more complicated case when we use more tools."

This means:
* On the client/browser, TS needs a transpiler to transpile to some non-ECMASCRIPT-modules.
* If you go go for "import ./myModule.js", IDEs might mark it as error.
* Other ALM-scripts which parse source-code (testscripts, mock-scripts, build-scripts, deploy-scripts, ...) might get confused.

Why not add an option to tsconfig and leave it to the developer to use it or not?
We know that is is not "pure doctrine" but for many cases it will work. One could also emit a warning "will only work with static files" or something like that.

I'm aware that "import ./myModule" could resolve to something which is not a static file on the web-server. E.g. a web-service dynamically resolving and returning js-code.

In any case, please such an option would leave it to the developer's resonsibility how to transpile it.

I think `add .js extenstions on imports when the output is esm/es2015` would be the only correct behaviour, because `The file extension is always necessary ` for relative specifier in esm.

@ioslh I'm trying to get eslint to be able to ensure ".js" extensions are never forgotten
any thumbs up or help in trying to make my PR be accepted would be appreciated:
 URL

TypeScript developers, please, do whatever the hell you want with file extensions, this debate has been going on for years, I don't care, your mind is set, fine. But just document this very basic thing in a place that's easy to find: how on earth do I run the JavaScript emitted by tsc when "module" is set to "ESNext"? That will save a lot of people a lot of time. Most people understand "transpiles to JavaScript" as "transpiles to working JavaScript". But this is not the case.

I'm hitting this exact same issue. I'm not using webpack, just plain typescript and my javascript output is broken because the .js extension is missing. How on earth can this not be a bug? What am I supposed to do instead?

@TheBoneJarmer If you're just doing plain TS and JS, use the would-be filename as the import specifier like so:

ts
import { version } from "./version.js";

The problem with this solution is that if you have an "outDir" different
than the default, i.e. a setup where transpiled files don't live beside the
.ts files, most tools will freak up and that's not a nice development
experience.

I was so pissed-up buy this that I built this monstrosity:
 URL

You can install it and have it watch your "outDir" and it will quickly and
transparently add the .js extension where appropriate to the transpiled
files as they appear / are updated by tsc.

It seems to be working well. Only missing major feature is that I currently
don't rewrite the source-maps but it doesn't seem to matter much since the
changes I make in the js files are only adding 3 chars to some import
statements at the end of some lines. No line offets, no changes to any
place where you would be likely nor even able to set a breakpoint anyways.

Give it a go and let me know of any issues you might find!

There are webpack modules that do the same thing, but my solution is much
less invasive: keeps file and directory structure, no bundling, no config.

I spent a considerable amount of time reading the obscure ESM spec and I'm
pretty confident my tool doesn't do anything unwise.

I actually think TS has it wrong, as the ESM spec clearly states that there
is no such thing as a default file extension. So you should "import foo
from '. /foo.ts'" and that should transpile to "import foo from
'./foo.js'". I don't see any deviation from JS here. "import foo from
'./foo'" seems just wrong.

On Thu, Jul 29, 2021, 22:43 RA80533 ***@***.***> wrote:

Thanks for the replies guys. Personally I entirely agree with @djfm. I am grateful for the workaround from @RA80533 though, don't take me wrong. But it is far from a good solution imho. And the reasons why are nicely explained by djfm. That said, you are not the only one who got that idea. I found another npm package through Google which does what I believe you do as well. It is called tsc-esm and is created by user @Gin-Quin.

That said. I also took my time to learn a bit more about the whole es6 module system and I also think javascript has a flaw here. Imho they should introduce something similar to what happens in urls with index.html. In most if not all web servers you never have to manually insert '/index.html' at the end of an url. When the path ends with a / the server automatically converts that to /index.html. When no file extension is added at the end of an import statement, the client should convert this first to .mjs. If no such file exists than to .js. And only then the client should throw an error if neither files were found.

Therefore I more or less can understand why typescript devs don't consider this a bug from their side. Typescript merely interprets the import statement for typescript purposes but may not be able to convert it that easily to esm. But I do think this should be a config option.

I mean, several users already created their own npm package out of frustration which I think shows how big this problem is. And they are right to be frustrated because my basic typescript app produces broken javascript, which is a definitely a bug from typescript. And the fact that typescript devs do not want to admit that is just plain ignorance and stupid. This will only push people away from using TS. And on top of that, the fact that they say they won't do a thing about it does pisses me off even more.

Imho the tsc should stop conversion when an import statement cannot be converted to esm. Or throw a warning or hint that narrows down to "Due to limitations in the javascript language you are supposed to add a .js in your import statement or else tsc will produce broken code". And I'd be fine with that but not the way it is now.

For a bit of clarity, this behavior is due to the way modern web authors tend to serve content. Web servers as a whole are glorified file systems. A request to `/` is semantically equivalent to inspecting the root directory yet, because web servers have optimized the browsing experience in a manner such that they aren't beholden to typical file system behaviors, that would-be directory request is often treated as a file request through some arcane redirection.

We should fork TypeScript. Let's call it FreeScript for instance.

There are way too many things in the hands of Microsoft right now and they
go way too well together: they have GitHub, Copilot (I'm in the preview and
it's pretty freaky), TypeScript, VSCode...

It's too good to be true. Our hands are tied. I have kind of a bad feeling
about this. Could turn out the wrong way.

I'd love something like a mix between TypeScript and Webpack. Except that
you wouldn't have to bundle up everything using hard to understand and hard
to configure plugins of plugins of plugins. But a lightweight, carefully
designed, and extensively tested layer of plugins on top of tsc could be
very nice.

Imagine how the language could grow if you could add rules to tsc via
plugins, like they do in eslint. Without any changes to JavaScript eslint
managed to get to a pretty good level of static analysis. Just imagine what
the community could do using TypeScript instead of JS.

How many times have I encountered a situation in TS where it wouldn't
compile even-though there was no way in hell the code could fail.

Like:

if (someArray.length > 0) {
 const x = someArray.pop();
 console.log(x.y);
}

Doesn't compile with strictNullChecks, x might be undefined. But i'm pretty
sure it may not.

But I digress, sorry.

On Fri, Jul 30, 2021, 09:09 RA80533 ***@***.***> wrote:

It creates non-valid ES6 code when given non-valid ES6 code. The first line in index.ts should be rewritten like so:

ts
import {start} from "./lib.js";

@RA80533, no, it creates non-valid ES6 code when given _valid_ TypeScript code.

I also just stumbled over this issue and as usual I find the justifications of "working as intended" as really questionable. There are various settings in the compiler which steer the module system. If I set `"module": "commonjs"` my typescript `import` statements are rewritten to `require`. There is also `esModuleInterop` which adds some extensions around the module imports.

While I agree that maybe the default behavior should be in the way that TypeScript leaves everything untouched, I also would say that it should/must be a TypeScript compiler setting to handle the mentioned use cases. I wanted to use TypeScript to create a small command line tool, which I can use in my GitHub Actions Workflow (without really making a reusable action) and it just does not work because the TypeScript output is not compatible with Node.js. Node.js seems to be usually a first class citizen in TS and here some very high level rules on the design goals (which IMO only partially apply here) prevent many people to use TS in such an obvious chain as running the compiled output in Node.js.

Maybe we have better chances with the Node.js guys to extend the module resolution algorithm.

Unbelievable how TS devs are stubborn on this.

On Tue, Sep 14, 2021, 11:33 Daniel Kuschny ***@***.***> wrote:

Expectedly I stumbled upon this when setting a simple Node.js module written in TypeScript and compiled to CommonJS and ES to cater for both cases. I agree with @ericmorand and other similar opinions that, given a valid TypeScript code and valid TS configuration to target ES, the compiler SHOULD generate valid ES code. Otherwise, it should be considered a BUG. If it's a design goal to not generate valid code from TS code, then the design is flawed and needs to be fixed too.

I tried to use typescript@`^4.6.0-dev.20211110`and set `module: node12` in `tsconfig.json` but the compiled code still does not include `.js` file extension. @pwhissell could you give more hints?

Indeed, Typescript is a "superset of Javascript". But what means to be a superset? It means:

1. you add more features to Javascript,
2. you compile those added features to be valid Javascript.

The most basic Typescript additional rule is: "you can type a variable". Like this:

ts
const value: string = "foo"

which will be *transformed* into `const value = "foo"`.

Okay. You add a feature. You compile to make the feature work with the language. A superset of Javascript.

Now there is another feature that is added by Typescript: the fact that the extension is optional.

You can write:

ts
import { imported } from "./my-module.js"

which is valid Javascript *and* valid Typescript. That's normal: Typescript is a superset.

But because of the Typescript-specific rule "make the file extension optional for ts/js files" (not a Javascript rule), you can also write (in Typescript only):

ts
import { imported } from "./my-module"

which is valid Typescript but **not valid Javascript**.

If you add a feature as a superset of a target language, then you ***must*** compile your feature into a valid output of yourtarget language.

And, yes, "make the file extension optional for ts/js files" is definitely a Typescript-specific feature.

I will add that I indeed created a library called `tsc-esm` as a workaround for this bug, and even though it works quite fine it has been a pain to develop and every time I use it (ie 100% of the times I need to create a library written in Typescript) I feel I should not have to patch the output of the Typescript compiler like I do.

I look forward the day when I can tag my library as "deprecated" :)

This whole discussion is absurd. Valid typescript obviously transpiles to invalid ES6 code. I do not understand in which world this can be classified as "works as designed" behavior. Adding ".js" to import statements which actually refer to ".ts" files as workaround is too wild for me. For my current project I have free choice, therefore I'm gonna switch over to CommonJS target module code. CommonJS works without file extensions. In case one can live with CommonJS target module, this is an option to get around this problem.

An alternative way to make this work without adding dependencies is to use Node's `--es-module-specifier-resolution=node` flag. For example, `node --es-module-specifier-resolution=node dist/index.js`, where `index.js` would itself have ES-style imports without the .js file extension.

I've created a pull request wich wich solve this for raltive imports, see:

 URL

I've added a compiler switch:

 appendModuleExtension

@RyanCavanaugh

This statement is simply not true! TS is a compiler and it is defined in the documentation as "TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.", in fact, it does even generate output not present in the input, for example, polyfills for handling "await" etc, depending on the selected target. So it is very much a compiler that outputs JS, the rest seems to be confabulation used not to fix issues that do not fit your current mental model of what TS should or should not do.

I think probably a thousand person, me included, have written similar scripts. This is just absurd.

@ahejlsberg Please help us in the name of practicality and peace of mind.

This conversation is really frustrating. While I can understand not adding the .js suffix under the rationale of not modifying Javascript (though I disagree with it), what I *cannot understand* is the compiler happily producing code that will fail to run. There should **at least be an option to fail compilation if I don't use a .js suffix in the import**. I don't even care if it's a default option, as long as it's exposed.

In the meanwhile, what do people recommend doing? What's the safest way to make sure tsc doesn't produce Javascript that will fail in this instance? I'm using node 16 and would really like top level awaits.

Yeah, it's not like there aren't already 1000 compiler options to tune the
behaviour of TypeScript, one more won't hurt...

On Sat, 23 Jul 2022, 19:13 Nathan Coleman, ***@***.***> wrote:

And to reiterate, I'm not asking for am option that rewrites the imports, just an option that makes the compiler say "hey, this probably isn't what you want and will generate broken code", like a fatal warning. There could even be a flag that would override the warning and allow compilation anyways.

So `"failOnInvalidModuleImport": true` in tsconfig (defaults to false), which would cause the compilation failure, and a flag `tsc --allow-invalid-module-import`which would ignore even if the setting was true, and compile anways.

TypeScript team, can you comment on adding an option like this? This is clearly a problem people have, and I can't see how exposing a default false option to give some greater compile safety could be a bad thing there. It would be a great way to earn some developer good will :)

As you all also see in my pull req, the rewrite are only a few lines of code

The recommendation to preemptively append `.js` extensions to TypeScript source is not only counterintuitive, it breaks ts-jest tests. It seems to me that TypeScript is in the wrong here. Why ban `.ts` extensions from import statements and encourage leaving them off altogether if the extension is resolved by the language server but *not* the compiler?

I just encountered this issue while attempting to port a library to TypeScript. I didn’t have to deal with it in prior projects because I was building apps with a bundler. Now that I’m emitting modules that can be tree-shaken downstream, this behavior, intended or not, leaves me in a bit of a pickle.

@adamshaylor for what it's worth, vitest supports `.js` imports in test code and is largely API-compatible with Jest.

good to see this crazy conversation still going after 2 years

its amazing to me that something so basic as module resolution continues to be one of the most frustrating things about the nodejs ecosystem

I cannot wait for deno to gain more traction and put this issue to bed by enforcing esm

to the TS team, listen to your users and add a compiler flag

I've got a react app that's being bundled with webpack, and a pure typescript server. The 2 projects share some model classes.

If I import my classes using the standard Typescript syntax `import MyClass from "./model/MyClass"`, I get the "cannot find module ... imported from ..." error.

Alright, fine, I can simply add the ".js": `import MyClass from "./model/MyClass.js"`

... This causes webpack errors "Module not found: Error: Can't resolve './MyClass.js' in "...""

This is infuriating

At first glance of the time of this issue, I think I'm lucky to find a perfect solution. Until scrolling to the bottom then I realize that I'm unlucky. So sad.

So weird. In VSC if you Cmd+click on a `import something from 'something.js';` you'll get to the .ts file, like VSC knows that this issue exists and "fixes it".

But wasn't it fixed?

To my greatest surprise, in my latest project, I'm using relative imports
in TypeScript without a file extension and the emitted JS just works!

On Thu, 3 Nov 2022, 15:51 Claudio Cicali, ***@***.***> wrote:

This has nothing to do with VSC and also works in every other editor with the typescript LSP. Completely unrelated to this issue.

2023 now, and the flicker of hope for this feature is still alive!
See URL

Here a few pull requests or issues, where i need only file extensions (.js) so I could use them in browser:

 URL
 URL

I don't know why an extra option wich I created in my pull request could not be added...

I know use a js script to add the extension afterwards, see the pull I creaed here on how to do: URL

Just leaving my `+1` here... can't believe this is still an issue.

Would be as simple as to allow using `.ts` extensions and then transform them into `.js`.

This would make everyone happy: hundreds of people asking for it and TS maintainers because TS principles will not be affected this way (read this comment).

Hope TS maintainers will reconsider this soon.

Cross-posting this comment which explains that this is, very much intentionally, not something we are going to do.


Question: [frontend] logs and artifacts stored in different Minio locations and can't be accessed by frontent?

@kubeflow/pipelines @HumairAK @pdettori I would like to ask that we prioritize this issue, it is a significant regression for V2 pipelines.

The gist of the issue is that when Argo Workflows has the `archiveLogs` config set (which we do at the cluster level in our manifests), then Argo Workflows automatically creates a "output artifact" called `main-logs` which full Pod logs of each step as an S3/MinIO artifact.

In Kubeflow Pipelines V1, we used to capture this output artifact, which allowed users to see the old logs when the Pod had disappeared, but in V2 this was strangely omitted.

Fixing it should be very straightforward, we just need to capture the artifact location of the `main-logs` output of the `executor` step, and store it as an "Output Artifact" in the ML Metadata of the step.

For reference, we can retrieve this artifact by reading the status field of the `Workflow` resource:

yaml
status:
 nodes:
 pipeline-1-8g5bs-3160443754:
 displayName: executor
 outputs:
 artifacts:
 - name: main-logs
 s3:
 key: artifacts/team-1/pipeline-1-8g5bs/2024/06/13/pipeline-1-8g5bs-3160443754/main.log

[frontend] logs and artifacts stored in different Minio locations and can't be accessed by frontent
### Environment

* How did you deploy Kubeflow Pipelines (KFP)? from repo
* KFP version: 1.7.0
To find the version number, See version number shows on bottom of KFP UI left sidenav. -->
* KFP SDK version:

kfp 1.7.0
kfp-pipeline-spec 0.1.9
kfp-server-api 1.7.0

### Steps to reproduce

* run a pipeline and store an artifact
* delete the pod

Then we see that:
* The artifact (and its preview) can be seen in the output list of Input/Output tab
* The metrics can be accessed by the visualisations tab
* A wrong link to the metrics is found in the outputs list of the input/Outputs tab
 * details read `Failed to get object in bucket mlpipeline at path v2/artifacts/pipeline/example pipeline/e154ea68-d59c-46ba-aea4-ead5b9eb0ea8/square/metrics: S3Error: The specified key does not exist.`
* The logs cannot be retrieved from minio in the logs tab
 * details read `Error response: Could not get main container logs: Error: Unable to find pod log archive information from workflow status.`

Looking in MiniO it seems
* the Artifact is stored at
`mlpipeline/v2/artifacts/pipeline/example%20pipeline/e154ea68-d59c-46ba-aea4-ead5b9eb0ea8/square/`

* and the logs and metrics are stored at
`mlpipeline/artifacts/example-pipeline-ljzls/2021/08/25/example-pipeline-ljzls-1034021739/`

minimal code sample:

python
import kfp
from kfp.v2.dsl import pipeline, component, Output, Metrics, Artifact

@component(base_image='python:3')
def square(x: int, metrics: Output[Metrics], data: Output[Artifact]):
 metrics.log_metric('test_metrics', 1)
 metrics.log_metric(f'{x} squared', x**2)
 print(f'{x} squared is {x**2}')

 with open(data.path, 'w') as f:
 f.write("some content")

@pipeline(name='example pipeline')
def pipeline():
 square(4)

client = kfp.Client(host=' URL
client.create_run_from_pipeline_func(
 pipeline, arguments={}, run_name='Example run',
 experiment_name='Default', enable_caching=False,
 mode=kfp.dsl.PipelineExecutionMode.V2_COMPATIBLE
)

### Expected result

The logs and metrics can be retrieved from MiniO by the frontend even when pods are deleted

### Materials and Reference

Is this a configuration issue? Should I move things to point only to v2 path?

---

Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

It has been one year, did anyone found out how to resolve/workaround this bug that'd be great, Im sure this is one of the major bugs.

Having the same issue with Kubeflow Pipelines 0.2.5 - if pods created by workflow are deleted, logs cannot be accessed from MinIO artifact store, even if they are archived there. Has anyone actually found a way to make this work ?

I think I found the root cause of the problem. It is likely that the schema for Argo Workflow status has changed, as the Argo Workflow fields that are retrieved by URL are not anymore where the ts code expects it. The code expects a workflow status with S3 info under the node's output artifacts, but Argo Workflow may have changed since when that code was written and those properties are now under:

status:
 artifactRepositoryRef:
 artifactRepository:
 archiveLogs: true
 s3:

According to URL URL should have fixed it. Do you still have issues?

I still have the issue with KFP 2.2.0, which includes #10568 - does not look like the UI was updated to retrieve the S3 log artifacts stored by Argo. I have a fix in my fork that shows what is needed for the UI to work with the archived logs - URL

Since this issue is about `V2_COMPATIBLE` mode I am going to close it as that mode is no longer supported.

However, as @pdettori (and the other recent comments have raised) there is a similar issue present in `V2` mode because we don't capture the `main.log` as an output artifact anymore.

Let's continue the discussion on the other issue:
- URL

/close

@pdettori I see in URL that you propose a solution to the V2 issue.

Can you please continue this discussion on the V2 issue: URL

[feature] display main.log as artifact for each step
### Feature Area
/area frontend
/area backend

### What feature would you like to see?
A feature similar to v1 behavior. In the details page of each step, the log appears as one of the artifacts that users can view:
image

In v2, this main log artifact is no longer displayed. It would be great if we could add a similar section to show the logs, or use the log artifact as a source for the "logs" panel after the pod is deleted, instead of directly pulling from the (already deleted) pod.

### What is the use case or pain point?

Because all the logs of completed pods are auto deleted by Kubernetes after 24 hours, the users can no longer access the logs of earlier pipeline runs.

### Is there a workaround currently?

No workaround.

/cc @kromanow94

---

Love this idea? Give it a 👍.

I read that this issue was not included in the previous release as mentioned in this comment , just wanted to ask whether we have an update on this or not.

/reopen

Is readding this feature to v2 planned for future releases? It would be very helpful.

I'm a bit unfamiliar with the v1 version of this, did this come from argo's archive logging feature?

In v2 kfp aims to be agnostic to the backing engine, so if this is an argo specific feature, we may need to consider a separate feature/proposal on how to handle persistent logging in general for kfp.

Yes, Argo Workflows stores the logs separately and given only kfp metadata, there currently seems to be no way to obtain the logs' locations. You'd need to access the Argo Workflow object directly to obtain the info.

Including this feature right into kfp would make sense and imo is much needed, as otherwise, users aren't able to view logs after the step's pod has been deleted.

Hi @HumairAK What do you think about this ?
Points:
- DS engineer would be interesting to see logs as artifact, as part of models producer investigation
- logs can have different retention against artifacts: user can clean them to reduce space usage
- it is better to have interactive logs

Thoughts:
- in launcher POD: use extra container for waiting logs and publish or use other approaches: fluentd.... it is up to user how to collect logs and put logs. But by default we will do by sidecar container. For this we should disable argoworflow logs.
- during run we subscribe real container logs stream (this logic already implemented)
- allow launcher use separate bucket for logs or use the same as artifact
- in sdk we should be able disable logs

I agree persisted logging is very important, but we should clarify if we need them as artifacts, or do users just want to see logs after pods have been removed?

For example, if we have persisted logs, the log viewer could instead fetch the logs from the persisted location instead of pods (I believe this is the logic currently present in ui, though it may not be utilized in v2). Could it be confusing to see 2 different locations where logs are being shown?

Not disagreeing, but could you elaborate on specifics?

I like the idea of decoupling implementation to existing solutions (or at least giving the user the option to, if we opt to natively implement),

I think we should also allow users to disable/enable not only in the SDK, but via api & ui as well.

Why engineers may interesting in this:
- some frameworks for ML logging kind of metrics
image
- kubeflow run is snapshot of inputs/intermediate/code/config which can help to reproduce or compare, so for the same combinations of inputs/intermediate/code/config, it is possible to have different logs due to different conditions in cluster: gpu, cpu, drivers.... that is why logs is part of this snapshot

v1 version was implemented correctly from concept view, because it combine logs interaction during run (life time stream from pod) and logs persistent for long term.

@sanchesoon Can you give more details on this workaround? I am currently using KFP `2.1.0` with the normal argoworkflow backend. I really want a way to provide users the ability to view their pipeline tasks' logs simply by clicking through the KFP UI.

Completely agree with @thesuperzapper. Having a run fail and not being able to determine the reason why because the logs are not available is a show stopper.

yes, This is show stopper and required to retrieve logs of completed DAGs

Hi
Yes I can.
In argo workflow you should use something like this:

 archiveLogs: true
 s3:
 keyFormat: {{ `"pod/log/{{workflow.name}}/{{pod.name}}"` }}

And patch frontend split function, frontend/server/workflow-helper.ts:

function workflowNameFromPodName(podName: string) {
 return podName.replace(/-system-container-impl-.*/, '')
}

And don't forget configure you kubeflow proxy frontend
kubectl -n kubeflow describe po ml-pipeline-ui

 ARGO_ARCHIVE_LOGS: true
 ARGO_ARCHIVE_ARTIFACTORY: s3
 ARGO_ARCHIVE_PREFIX: pod/log
 ARGO_ARCHIVE_BUCKETNAME
 AWS_ACCESS_KEY_ID
 AWS_SECRET_ACCESS_KEY
 AWS_REGION
 AWS_SSL
 AWS_S3_ENDPOINT
 AWS_PORT

My team and I are making good progress. We have a functional POC. It just needs some polish. It involves sending the run execution date to the logging handler since the current AWF configuration stores the log artifacts in date-based subfolders (to reduce the likelihood of collisions (see URL The existing code is more or less fine, it's just looking for the logs in the wrong location. The UX for this will be a bit different than v1. Logs will not be listed under output artifacts. Instead, when the logs tab is loaded, if the k8s pod is not accessible, it will populate the react component from the artifact store instead.

@droctothorpe however you do it, make sure that you don't assume anything about the structure of the Argo Workflows `s3.keyFormat` as that is not guaranteed to be the same in all environments.

For example, some users have changed their key format to a different prefix or path structure which may or may not be the same as the current default in Kubeflow Pipelines.

That's why I said in URL that you have to get the true path from the workflow status.

@thesuperzapper, if I understand the logic correctly, the handler does in fact try to get the log artifact path from the workflow status **first** (if the k8s pods have been garbage collected). It only tries to call the artifact store directly (in a way that currently makes incorrect assumptions about where the log is located) if the workflow has been garbage collected.

The logic tries to retrieve the logs from multiple sources in the following sequence:

1. It tries to retrieve the logs from the pod (link).
2. If that fails, it tries to retrieve the logs path by extracting it from the workflow CR (function invocation link, function definition link (with some nesting)).
3. If that fails **and** `archiveLogs` is true (this is set in config.ts), then and only then does it try to retrieve the logs directly from the artifact store without pathing through the workflow CR. Currently, master makes incorrect assumptions about the path (here is where it is constructed) that are at odds with the keyFormat default in the `workflow-controller-configmap` object.

@sanchesoon's suggestion essentially reverts the log location, but URL and the comments in the configmap convey that dates were deliberately added to the path to reduce the likelihood of collisions.

Our fix essentially corrects the assumption and is only applicable if the workflow has been garbage collected.

If a user both modifies the keyFormat **and** deletes the workflow CR, option 3 will not work. Why would a user want to modify the keyFormat though? Is that a rare enough edge case that solving for it would constitute bike-shedding? If not, there may be a way to have the handler call the K8s API to lookup the `workflow-controller-configmap`, extract the `keyFormat` and translate it somehow in a dynamic way that the function could parse, but that would (a) add latency, and (b) probably be a PITA, especially figuring out how to map the Go templating syntax to specific parameters in the function in a way that properly accounts for the sundry variants in the template tags.

Relevant meme:
image

@droctothorpe

If I understand correctly, this is only the case until the information about where the log artifact is stored is saved to the pipeline run artifacts, right? I take that this is the assumption because it wouldn't be too good to have a requirement of storing the Argo WF CR Objects on the etcd indefinitely. And if this assumption is right, we can use a very simple K8s mechanism to prevent users from manually deleting the WF CR objects before the information about where is the log artifact is stored to Pipeline Run Artifacts - finalizers.

If we were to use finalizers, we can just make the assumption that we control when exactly the Argo WF CR is released to be GCed and simplify the scenario a bit.

There can be some requirement or limitation where you'd have to reuse the same S3 Bucket for multiple purposes (like multiple KF Instances or a general bucket for logs from multiple sources) because of how a company/organization manages the infrastructure (so in this example you're given an S3 Bucket with a specific prefix where you can save the logs artifacts, lets say `/artifacts/kubeflow/{{workflow.namespace}}/pod/log/{{workflow.name}}/{{pod.name}}`.

Another example would be if each KF Profile is serving a different team and you're hoping to achieve full Profile isolation where Team A doesn't have any form of access to the logs of Team B. This is something similar to what @thesuperzapper pointed out in the URL `artifacts/team-1/pipeline-1-8g5bs/2024/06/13/pipeline-1-8g5bs-3160443754/main.log`.

Also, in enterprise environment, you're rarely given the full freedom over your infrastructure and it would be a real issue if something as simple as the `keyFormat` would be a blocker in adopting KF.

@kromanow94 Thanks for the context!

Correct. Workflows gets GCed after a specified length of time as defined by the TTLStrategy field. Even after workflows are deleted, the corresponding logs persist in the artifact store.

Any objections to letting end users specify the typescript equivalent of an f-string through an env var via `config.ts`? We could document some predetermined variable names that map to what's available in the corresponding handler (e.g. namespace, pod name, date, etc.), and add a comment to the `keyFormat` field stating that if it's modified, the corresponding field in `config.ts` should be updated.

The alternative is making the logs explicit output artifacts in MLMD. I would be curious to hear from Google about why that was disabled in v2 before reverting it. Output artifacts are first class citizens with dedicated nodes in the v2 graphs; we probably don't want every component to have a corresponding log node in the DAG, so we'd have to handle that in the graph rendering logic as well.

@droctothorpe

More a doubt than an objection - maybe going for the env var via `config.ts` is just not required at all? If we were to use the finalizer pattern, we assume that it's not required to _reverse engineer_ where the logs _might_ be stored. I think the information about the log URI location should be an integral part of the KFP Step and once that step is finished, we should only reference the KFP Step to get the information where the log artifact is stored.

But, maybe there is something obvious I don't see that conflicts with this approach. At end, what I think makes sense is to somehow save the address of the logs and put it together with the Step Execution. If this can be stored again in the MLMD, great. If not, is there any other place where we can store it? Maybe this is the part I don't yet fully understand - if the log artifact URI is not saved in the MLMD, do we have any other place where we can store that information, or currently we're forced to guess where the logs might be through the `config.ts`?

Currently, the UI is just guessing and guessing incorrectly, heh. If we store it as an output artifact in MLMD, that removes any guess work but substantially broadens the scope of the changes and will definitely require design review from Google.

Another argument in favor of storing the log as an output artifact is what if an admin elects to update the keyFormat? The logs for historical runs will no longer be accessible, and there won't be a way for the UI to support both the old and new patterns at once.

My personal preference for maturity and stability would be to go with the MLMD and google review or an alternative store if possible. I'd even investigate if creating additional table in the mlpipeline db makes sense just to store the log artifacts URIs for given Step ID. Considering all the discussion, I don't feel competent enough to suggest if the workaround with the env var in the `config.ts` is suitable for now... If I were to make this decision myself, I wouldn't do it.

I'm starting to lean in that direction as well, but what the heck do I know, I am just a ~plebe~ user.

Does ya'll think it make sense to submit a smaller, discrete PR that corrects the UI's incorrect guess _for the time being_ until we can implement a broader fix that adds the log URI to MLMD? We can aim to submit the PR tomorrow (at AWS Summit all day today) to give you a sense of the scope.

If this can be added to the KF 1.9 then maybe it makes sense to unblock this with the idea you've proposed with `config.ts`. If it's not going to be a part of the v1.9 release because how short on time we are, maybe not so much.

I just want to highlight what I said in URL again.

This is very clearly an accidental regression, because KFP V1 stores the logs in an MLMD artifact (it just did not automatically forward the logs tab to the appropriate artifacts and required users to click the step and view it).

The only additional complexity (which is probably why this was overlooked) is that in KFP v2 now each step is more than one container, each with its own logs.

Assuming we store the logs for all steps as an artifact (even the non-executor steps) we should correctly show them separately in the logs tab probably with some kind of sub-tab for each container.

@chensun @zijianjoy @connor-mccarthy Do you have any objections to adding the driver and executor logs to the list of output artifacts for each component? I just want to make sure that removing that functionality was not a deliberate design choice before we re-implement it in v2. Thank you!

I think the executor outputs are being extracted from the IR, and currently the IR doesn't include information about the container logs. We need to decide if we want to include the container logs as executor outputs, which is quite complicated because (a) the path is dynamically inferred by `keyFormat` (for AWF) and not available client-side at IR compilation time, and (b) is extremely AWF specific in a way that could undermine workflow orchestration agnosticism in the IR.

POC for the interim solution: URL This will make it possible for anyone to implement a solution in a way that accommodates their unique `keyFormat` syntax without having to modify the actual code.

I plan to join the community call tomorrow to hear from Google about the proposed target-state solution of storing logs as output artifacts.

URL was just merged 🎉 . It might make make sense to keep this issue open to continue discussion about wether or not to / how to surface driver and executor logs as explicit outputs in the GUI.

Hey, I noticed the PR is already included in the `2.3.0`. I'm trying to run some tests but I get the following error and I'm not able to get the logs from the Pod Step. I'm having two issues:

The `ml-pipeline-ui` Pod is exiting the main process with the following error:

/server/node_modules/node-fetch/lib/index.js:1491
 reject(new FetchError(`request to ${request.url} failed, reason: ${err.message}`, 'system', err));
 ^
FetchError: request to URL failed, reason: getaddrinfo ENOTFOUND metadata
 at ClientRequest. (/server/node_modules/node-fetch/lib/index.js:1491:11)
 at ClientRequest.emit (node:events:517:28)
 at Socket.socketErrorListener (node:_http_client:501:9)
 at Socket.emit (node:events:517:28)
 at emitErrorNT (node:internal/streams/destroy:151:8)
 at emitErrorCloseNT (node:internal/streams/destroy:116:3)
 at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
 type: 'system',
 errno: 'ENOTFOUND',
 code: 'ENOTFOUND'
}

In the short period of time when the `ml-pipeline-ui` is responsive before it's exiting with the above mentioned error code, I'm getting this error:

Could not get main container logs: Error: Unable to retrieve workflow status: [object Object].

Do you know what might be causing the issue?

FYI, I was testing with kubeflow/manifests 1.9.0 and only changed the container images tags for pipeline components to `2.3.0`.

@kromanow94, someone in the (deprecated) Kubeflow slack workspace recently DMed me reporting what looks like a very similar error and a corresponding solution:

 WF manifest lookup -> artifact store lookup) is defined here. Note that the third step only executes if `archiveLogs` is true.

I also run another scenario with one of the default pipelines. Using the `Run of [Tutorial] DSL - Control structures` will create a set of Pods with the following names:

tutorial-control-flows-gbjpn-system-dag-driver-1941995042
tutorial-control-flows-gbjpn-system-dag-driver-2529298331
tutorial-control-flows-gbjpn-system-container-driver-3821465773
tutorial-control-flows-gbjpn-system-container-driver-467613593
tutorial-control-flows-gbjpn-system-container-impl-2018360503
tutorial-control-flows-gbjpn-system-dag-driver-3793006146
tutorial-control-flows-gbjpn-system-container-driver-1781539373
tutorial-control-flows-gbjpn-system-dag-driver-1653906037
tutorial-control-flows-gbjpn-system-dag-driver-477249553
tutorial-control-flows-gbjpn-system-dag-driver-3564565339
tutorial-control-flows-gbjpn-system-dag-driver-511401279
tutorial-control-flows-gbjpn-system-container-impl-1647980155
tutorial-control-flows-gbjpn-system-container-driver-133111245
tutorial-control-flows-gbjpn-system-container-impl-902191899
tutorial-control-flows-gbjpn-system-dag-driver-2964226956
tutorial-control-flows-gbjpn-system-dag-driver-820485803
tutorial-control-flows-gbjpn-system-container-driver-2311769198
tutorial-control-flows-gbjpn-system-container-impl-3092937256

With the pipeline above, I confirm the mechanism works and I was able to get to the logs through the artifacts when the Pod was no longer available on the cluster.

For my other test I used pipeline created with the following script:

from kfp import dsl
import kfp

client = kfp.Client()

experiment_name = "my-experiment"
experiment_namespace = "glo-k8s-admin"

@dsl.component
def add(a: float, b: float) -> float:
 """Calculates sum of two arguments"""
 return a + b

@dsl.pipeline(
 name="Addition pipeline",
 description="An example pipeline that performs addition calculations.",
)
def add_pipeline(
 a: float = 1.0,
 b: float = 7.0,
):
 first_add_task = add(a=a, b=4.0)
 second_add_task = add(a=first_add_task.output, b=b)

try:
 print("getting experiment...")
 experiment = client.get_experiment(
 experiment_name=experiment_name, namespace=experiment_namespace
 )
 print("got experiment!")
except Exception:
 print("creating experiment...")
 experiment = client.create_experiment(
 name=experiment_name, namespace=experiment_namespace
 )
 print("created experiment!")

client.create_run_from_pipeline_func(
 add_pipeline,
 arguments={"a": 7.0, "b": 8.0},
 experiment_id=experiment.experiment_id,
 enable_caching=False,
)

Which creates Pods with following names (the name differs from example in previous comment because it's a new run):

addition-pipeline-8fbx5-1329381822
addition-pipeline-8fbx5-2476489665
addition-pipeline-8fbx5-2909346888
addition-pipeline-8fbx5-579177391
addition-pipeline-8fbx5-822281223

If I understand correctly, this is because of how the Workflow Name is being provided by formatting the pod name:

 URL

 URL

Is this because of the difference in how the KFPv1 and KFPv2 works?

Also, in case it's related, please make note of this issue: URL

That being said, continuing to do some extra validation on my end to see if I can repro the error.

Hey @droctothorpe , were you able to have a closer look here?

TBH, I'm not exactly sure if the Pipeline I created using the script from URL is KFP v1 or KFP v2. I deployed it using `kfp==2.8.0` so I assumed it's KFP v2. Do you know if I should change anything in the script to explicitly configure it for KFP v2?

When I ran that same pipeline, my pods had different names (i.e. they adhered to the v2 nomenclature):
<img width="657" alt="image" src=" URL

Are you positive that you submitted the run with v2?

FYI an easier fix to this is adding the following env var to the ml-pipeline-ui:

yaml
- name: DISABLE_GKE_METADATA
 value: "true"

Shout out to @boarder7395 for sharing it.

@kromanow94 I think you might be having the same issue I did.

The two changes required for everything to work are
* Update environment variable ARGO_KEYFORMAT on deployment ml-pipeline-ui to any format you want (we include {{workflow.namespace}} to ensure separation of tenant data assets).
* Update the workflow-controller configmap value of keyFormat to be the same format as above.

What I missed was the second item which resulted in the issues you had above.

Hey, I was able to get the `main.log` artifact after the Workflow and Pods were deleted with latest version from `kubeflow/manifests` `v1.9.1` which uses the Kubeflow Pipelines version `2.3.0`.

I only had to put those two env variables for the `ml-pipeline-ui` Deployment and all works:

yaml
- name: ARGO_ARCHIVE_LOGS
 value: "true"
- name: DISABLE_GKE_METADATA
 value: "true"

Though still a workaround in code, it works.

Are there any plans for the proper solution that registers the `main.log` as artifact?

I started working on turning the outputs into proper artifacts. There are a lot of complex design obstacles. There's no simple way to do it that preserves backend agnosticism. We have to decide if we want to rely on AWF to archive the logs and just record the relationship between the execution and the log files in MLMD, which is extremely backend-specific, or just have the launcher capture and publish logs directly, which is kind of reinventing something that AWF already does, and also doesn't account for driver logs. Bandwidth permitting, I may author a design doc. Maybe we can discuss it in the community call.

As far as I understand, current solution is a workaround where the dashboard is just configured to look for the main.log in specific places (bucket and path key format). It’s not the main.log URI stored as part of the KFP Step.

Should we reopen until we have a more robust solution (like storing the main.log as a step artefact) or we should create another issue to track it as another feature?

Heads up, friends, we implemented a deeper fix that stores the component log paths directly in MLMD for v2 in this PR.

I'm reopening it as it's not yet implemented (soon to be with the above linked pr 🤞🏾 )


Question: Fix aarch64 dmg (MacOS Silicon version)?

This is macOS' gatekeeper (no idea why apple thought it's a good idea to show such a misleading error). It blocks all downloaded apps which are not signed, so the only real solution is to give Apple 100$ to buy "trust" :(

Fix aarch64 dmg (MacOS Silicon version)
This issue is being opened because the aarch64 version is damaged: URL

Also because a possible solution is referenced at:
 URL

So, I'll see if it's possible to fix it for the next version.

@YinMo19

 URL

Yes, I'm somewhat familiar with these commands. What I didn't know about was the `com.apple.quarantine` attribute. That's a good tip 😜

I'm familiar with building **dmg** files on Mac, so I could create a custom one where I could add all the information you mentioned. However, I have a feeling the cause of the error must be related to _Tauri v1_ and its build configuration, but I haven't done much research either.
- URL
- URL

I'll try to see if I can fix this in the next few days, as I'm a bit stuck.

Anyway, as a temporary solution, I think I'll add the information you mentioned in the _README_.

---

 URL

I've used this project in the past: URL
to create pretty custom DMGs programmatically. If you're not familiar with it, I highly recommend it 😜

### **SOLVED!**

This issue affected all versions of MATE from _0.1_ to _0.2.3_.

The issue appears to be related to the `tauri.conf.json` configuration and building the application on macOS >= 10.14.0.

The issue has been resolved by adding to `tauri.conf.json`

json
"macOS": {
 "signingIdentity": "-"
}

### References to this issue:

- URL
- URL

---

Thanks to @YinMo19 for providing a temporary solution to open the damaged dmg in versions _0.2.3_ or lower.

Beautiful! That's exactly how it should be done. It seems that my approach is just a temporary solution and not having to patch it up is wonderful.

Tauri app labeled as "damaged" on macos when installing
### Describe the bug

I was playing around with Tauri and made a sample hello world app. When I bundled it, it was installable on my computer. However, when I tried installing on another m1 mac, it said the app was damaged and could not be opened. Running `xattr -cr /Applications/my-app.app` removed the issue.

IMG_5903

### Reproduction

1. Create a new tauri project using the cli
2. Build it using `tauri build` on a M1
3. Try installing on another M1 machine

### Expected behavior

I expect the app to be installable.

### Platform and versions

Environment
 › OS: Mac OS 13.0.1 X64
 › Node.js: 16.14.0
 › npm: 8.3.1
 › pnpm: 6.11.0
 › yarn: 1.22.15
 › rustup: 1.25.1
 › rustc: 1.65.0
 › cargo: 1.65.0
 › Rust toolchain: stable-aarch64-apple-darwin

Packages
 › @tauri-apps/cli [NPM]: 1.2.1
 › @tauri-apps/api [NPM]: 1.2.0
 › tauri [RUST]: 1.2.1,
 › tauri-build [RUST]: 1.2.1,
 › tao [RUST]: 0.15.6,
 › wry [RUST]: 0.22.5,

App
 › build-type: bundle
 › CSP: unset
 › distDir: ../dist
 › devPath: URL
 › framework: React

App directory structure
 ├─ dist
 ├─ node_modules
 ├─ public
 ├─ src-tauri
 ├─ .git
 ├─ .vscode
 └─ src

### Stack trace

_No response_

### Additional context

_No response_


Question: Deleted and then recreated Github repository can't be cloned?

Thanks for the update @AngeloSolusys. Can you try cloning the repository via the command line (`git clone `) to see if that succeeds? I

Deleted and then recreated Github repository can't be cloned
### Describe the bug

After deleting and then creating another repository with the same name, I couldn't clone the new repository in Github Desktop.

### Version & OS

Windows 10, Github Desktop version 2.5.6

### Steps to reproduce the behavior

1. Create repository online
2. Delete repository online
3. Create new repository using the same name online
4. Attempt to clone the new repository

### Expected behavior

It should clone the repository just fine.

### Actual behavior

I got the message "We couldn't find that repository. Check that you are logged in, the network is accessible, and the URL or repository alias are spelled correctly."

### Screenshots

### Logs

2020-10-26T21:38:03.377Z - warn: [ui] fetchRepository: 'MasquitoWasTaken/masquito-backend' returned a 404
2020-10-26T21:38:03.493Z - warn: [ui] fetchRepository: 'MasquitoWasTaken/masquito-backend' returned a 404
2020-10-26T21:38:03.493Z - info: [ui] [AppStore.getAccountForRemoteURL] no generic credentials found for 'MasquitoWasTaken/masquito-backend'
2020-10-26T21:38:03.494Z - info: [ui] proxy url not resolved, protocol not supported
2020-10-26T21:38:03.568Z - error: [ui] `git -c credential.helper= clone --recursive --progress -- MasquitoWasTaken/masquito-backend C:\Users\Gabriel Pizarro\Documents\GitHub\masquito-backend` exited with an unexpected code: 128.
stderr:
fatal: repository 'MasquitoWasTaken/masquito-backend' does not exist

### Additional context

Check out my repository at URL it does exist. I can also manually clone the repo from CLI.

I have a fresh install of GitHub Desktop and still having this issue. Any other suggestions?

Nevermind, my issue was that when choosing "Open With GitHub Desktop", it was not entering the entire URL correctly. I added ".git" at the end and cloned successfully.

I was no longer able to reproduce this issue, so I'm going to close it as resolved. I believe it was likely fixed by the work done in URL If you are still able to reproduce this issue, please let us know and we can investigate further.

We couldn't find that repository. Check that you are logged in, the network is accessible, and the URL or repository alias are spelled correctly.
Describe the bug
When cloning a repository (Note that repository is correct), it keeps getting an error. Error will be: We couldn't find that repository. Check that you are logged in, the network is accessible, and the URL or repository alias are spelled correctly.

Version & OS
Open 'About GitHub Desktop' menu to see the Desktop version. Also include what operating system you are using.

Version 2.5.6 and Windows 10.0.19042

Steps to reproduce the behavior
Go to 'Github Desktop'
Click on 'Your Repositories'
Click the 'Clone Repository'
Type in your 'URL or username/repository'
Click 'Clone'
See Error

Expected behavior
Get the repository cloned.

Actual behavior
When clicking on the Clone it keeps getting the Error: We couldn't find that repository. Check that you are logged in, the network is accessible, and the URL or repository alias are spelled correctly.

Screenshots

image

Logs
2020-10-27.desktop.production.log

Additional context
Add any other context about the problem here.

@AngeloSolusys thanks for the report. If you go to the `GitHub.com` tab is the repository visible there? Have you tried cloning any other repositories?

Yes, when I log on `GitHub.com` the repository is there.
When I tried to clone other repository worked ok

image

Log File today:
2020-10-28.desktop.production.log

This sound very similar to #10923 and I'm starting to suspect this could have something to do with URL

@AngeloSolusys Was the repository in question deleted or renamed at any point in the past?

Actually yes. I was making some tests and I created the repository Monitor, uploaded some files and then deleted it, after that I created another repository with the same name, uploded some files again and then deleted it again. I've done that about 3 or 4 times, (I can't remebem exactly how many times) in about 1 hour, the first times I was able to clone it but then in some point I couldn't clone the repository anymore using github desktop.

I tried to clone it using the command line and it worked.
image

I have the exact same issue. This is probably a duplicate of #10923

I face the same issue when trying to clone the wiki of a GitHub Repository.
The repository in question however, was never deleted, renamed or similar.

The logs also don't mention anything about a failed cloning or the repository in question.
2020-11-07.desktop.production.log

Hey, I also encounter the same blockage. Whether I make the project public or private, it doesn't change anything. On the other hand, via Visual Studio Code no problem for cloning.

The repository in question however, was never deleted, renamed or similar.

@Andre601 there are some known issues working with wikis. See URL If you are running into specific authentication issues please open a new issue and we can assist you further.

@bryx it would be helpful if you could open a new issue and fill out the issue template. Thanks!

You can completely remove github desketop from you PC and install again, remember don't forget to delete Residual file!!!

1

Then it can be solved.

But I believe it's better to find and solve the problem than try to find ways to hide the problem, cause cloning the repository in other ways is easy, I already have done that. i just reported the problem for it to be resolved.

I also have the same problem. Signing out from my account and then logging in didn't help.
I use GitHub Desktop for macOS Version 2.6.1.

Use Git GUI to clone it, then "Add local repository" from GitHub Desktop to circumvent this issue.

Well, if it's the case i'm closing the issue cause i've already got what i need, but the problem remains on the app

I'm having this problem as well. Suddenly today on Windows I stopped being able to authenticate via command line using a PAT (though it still works on macOS and it worked that last time I was on Windows with no changes).

@dmauro this issue tracker is for GitHub Desktop. For Git authentication issues I'd recommend reaching out to GitHub Support.

I had the same problem as described above. Seems to be similar to #10923 #7634 and other issues. Thank you @CaptainJackey : your advice solved my problem. I wish I would have found a more "elegant" solution, but de-install, re-install is probably the easiest one for a novice like me.

I just had the same problem with the latest GitHub Desktop 3.0 and manually solved it following the advice from @CaptainJackey. This is an active bug and shouldn't be marked as closed.

I just completely unistall and install it again as suggested and it worked!
Thanks

Error still exist on Mac. After reinstall User and Pass is ask for the repo but still not getting in. Other repos clone without problem. New repo won't

@Quinienl
I was having the same error, it worked on my macOS and my Windows after I logged out and logged back into my Github desktop account.
You go to File -> Options -> Account.

Iae pessoal, tudo certo ?, estava com o mesmo problema
Solução:: desinstalei, apaguei os arquivos adicionais e reinstalei

funcionou de boas

I also solved this problem by re-logging in, thank you very much!


Question: Gitpod in Mumbai region?

We discussed that we would want to go with the solution outline in #5596. Give our priorities atm this will have to wait a few weeks. Let's aim at scheduling this by mid October.

Gitpod in Mumbai region
_Issue tracked as part of URL

The latency experienced by me in Rajkot, Gujarat, India is about 300ms. This leads to a subpar experience. I'm on an FTTH connection whose bandwidth is 80Mbps down and 40Mbps up. Please refer to the attached screenshots. I've also attached a screenshot showing the latency of various GCP regions from my location.

It would be nice to see Gitpod deploying a cluster in India as India houses a sizeable proportion of developers and is one of the largest markets for off-shore development.

Screenshot 2021-10-10 at 9 55 18 PM
gcp_latency
<img width="395" alt="Screenshot 2021-10-10 at 10 13 08 PM" src=" URL

:wave: hey there, please refer to URL as the source of truth for supporting more regions than just EU and US. We are closing this issue to consolidate to the single issue.

Please see related comment on #7489, copied below:

---

There seems to be some confusion that is related to the closing of the following issues:

 URL
 URL
Please note: This is not a an update of the status of this issue (closing or opening). The reason for the consolidation is that we now have a proliferation of different regional issues being raised by users. It doesn't make sense for users to directly raising issues about specific required regions, as when it comes to rolling out new regions we'll need to review:

Costings
Latencies
Current + predicted future usage of Gitpod
...and many other factors.

It makes sense for this conversation to happen in a single issue, which is this one. Please continue to share any thoughts or feedback. We'll look to update the description soon as a consolidation of current thinking, as there are now multiple region related issues with many comments.

Thanks all 🙏

Gitpod Singapore (sg) region
_edit: :wave: hey there, please refer to URL as the source of truth for supporting more regions than just EU and US._

We have discussed internally regarding creating a new region a few times since the team has expanded to include two employees in Australia but a feature request has never been logged.

I've always found Gitpod workable when connecting from the US or EU clusters from Australia but the experience could be better.

This morning I received customer feedback which has prompted bringing this topic up once again:

I think the GCP Singapore region would be an appropriate choice for expansion for Gitpod. Singapore is also a region for GitHub Codepsaces btw.

nb. I was on 1 bar of Telstra 4G when performing this test.

 Front conversations

Hi Geoff, the name's Joshua from Indonesia. Been a fan of what Gitpod is working on for quite some time. All the best to the Gitpod team. Hope this helps.
image
image

Hi, it feels awesome to know that gitpod is finally going to have a Singaporean cluster! I'm from Bangladesh and I have been using gitpod for a 4G mobile network.
Thanks!

Screenshot_20210906-102807

Screenshot_20210906-103306

From Perth, Western Australia

Wired VDSL (17/7 down/up Mbps)

Appears my traffic is being routed via East Coast AU instead of direct to Singapore. Rough speed test shows 53ms from me to NewMedia Express SG which is what I'd expect.

image

Melbourne fibre connection (not NBN).

Screen Shot 2021-09-06 at 3 28 31 pm

Cool! thanks for all the comments. Let's do this!
@meysholdt can you take over and share a plan for rolling this out?

happy to do so. There are two possible setups for this:
a) setup a workspace-cluster in Singapore, hook it up to the us-meta-cluster and have have our server component route starting workspaces to the geographically closest workspace cluster (Singapore or US).
b) setup a workspace-clusters, a meta-clusters, and a database in Singapore and have the GCP LoadBalancer route users to the geographically closest region.

I'm in favour of (a) because it is the way to go if we want to support more than three regions: it has lower cloud costs, lower operational effort and more control over workspace-routing, etc.

However, our server (or bridge) component does not yet support geography(e.g. latency) based routing and we need to decide if that's a feature we we wan to implement now.

@meysholdt If that sounds difficult, it would be great to add a preference in user settings to choose the data center they want. WDYT?

Here is a proposal on how we could do automated latency-based workspace-cluster-selection: URL

Agree, this is something that would provide unnecessary complexity for the user. 🐼

FYI, one more data point from @tnir in URL (from Japan, I believe) :

removing from Platform Inbox because this depends on URL See Sven's comment on how we should proceed.

Our engineers in APAC would be your best friend if there was a Gitpod cluster local to them in either Singapore or Mumbai 😁

Here's the GCP Ping from one of our engineers in Hyderabad, India
image

Can we pay extra to have a cluster get spun up in whatever GC supported area? Would love something in Sydney.

Can't speak for Gitpod's team, but I think the more realistic answer that is to self-host: URL

Maybe I'm wrong though and they'd be willing to explore bespoke regions if the price was right.

Me too. I'm in Sydney [1] as well (and I work at Gitpod). I find the latency workable but indeed it could be better. All in good time. Gitpod is right now working on getting underlying primitives for architecture solid to make it possible to deploy anywhere and keep operational support costs (human time) scalable. Hold on. It'll be worth it.

[1] URL

I live in Seoul, but somehow Hong Kong wins with the least latency. I assume the actual DC isn't located in Seoul, as that wouldn't make much sense economically.

I have pretty good internet connectivity (~400mbps).

Screenshot_20211210-181713_Chrome

I would be satisfied with a Singapore cluster to be honest.

City: Krung Thep Maha Nakhon (formerly, "Bangkok")
Connection: AIS Fibre

<img width="1490" alt="image" src=" URL

This issue was in the inbox of the platform team for some reason. However, there is not much the platform team can do here. Much rather
* the workspace team would need to set up a cluster in the desired region
* also, on the WebApp side newly starting workspaces would need to be routed to the new cluster based on latency. Not sure if this falls into the area of team workspace or team WebApp.

I'm moving the issue to the inbox of the workspace team so that they can handle prioritization/planning.

Adding a "me too". I am considering Gitpod for my team in Singapore, Thailand and the Philippines - but the ping time to EU/US makes it extremely painful (I'm getting between 200-400ms and I am on gigabit fibre).

I'm from Taiwan, and I connect Internet with a Wi-Fi from a optical fiber network:

<img width="1440" alt="截圖 2022-05-26 上午9 27 04" src=" URL

<img width="992" alt="Screen Shot 2022-08-25 at 7 33 40 PM" src=" URL

Please see related comment on #7489, copied below:

---

There seems to be some confusion that is related to the closing of the following issues:

- URL
- URL

Please note: This is not a an update of the status of this issue (closing or opening). The reason for the consolidation is that we now have a proliferation of different regional issues being raised by users. It doesn't make sense for users to directly raising issues about specific required regions, as when it comes to rolling out new regions we'll need to review:

Costings
Latencies
Current + predicted future usage of Gitpod
...and many other factors.

It makes sense for this conversation to happen in a single issue, which is this one. Please continue to share any thoughts or feedback. We'll look to update the description soon as a consolidation of current thinking, as there are now multiple region related issues with many comments.

Thanks all 🙏


Question: Parser Error: Native class "EditorSpinSlider" cannot be constructed as it is abstract.

Yes, please comment on it that it solves the problem for you to help it along, it's still waiting for a decision

Parser Error: Native class "EditorSpinSlider" cannot be constructed as it is abstract.
### Tested versions

v4.3.beta2.mono.official [b75f0485b]

### System information

Windows 11

### Issue description

I'm working on a new plugin to build by procedural nodes via visual scripting and build my own custom graph nodes.
As example:
image

To have the same Look&Feel I rebuild the property editors used by the Godot editor inspector. (The original property editors are not public, but why?)

I used the Godot provided class EditorSpinSlider
And it works fine, so far so good.

But i have a unit test coverage and it fails when loading my ui components by error

Parser Error: Native class "EditorSpinSlider" cannot be constructed as it is abstract.

From the documentation, it is not abstract.
This blocks me actually to develop and test the scene and often needs a restart of the Godot editor.
It also blocks me to write unit tests because the scene is loaded via a test API and not instantiated by a plugin.

### Steps to reproduce

Use the attached example plugin.
When the project opened, it shows the example in the bottom.
image

The scene is loaded and the custom panel using the `EditorSpinSlider` works fine.
But when you try to run the panel scene itself, it fails with the error.
`Parser Error: Native class "EditorSpinSlider" cannot be constructed as it is abstract.`
image

This makes it impossible to test the scene manually or by a testing framework.

### Minimal reproduction project (MRP)

EditorSpinSlider.zip

Correct me if I'm wrong, but I think it's because `EditorSpinSlider`, being an editor control, is only available when running inside the editor, so they cannot be constructed when running the scene as a game.

Probably the same issue as #73525.

Yes is described as editor control, but creating a scene and running it for testing makes it impossible if it is recognized as abstract.

EditorExportPlugin raises error everytime you run the game with F5 because of "abstract native class"
### Godot version

4.0 rc2

### System information

Manjaro Linux using i3, Foward+

### Issue description

I've added an ExportPlugin to my addon and everytime I run the game in the editor I know get this error:

SCRIPT ERROR: Parse Error: Class "eh_UtilitiesExportPlugin" cannot be constructed as it is based on abstract native class "EditorExportPlugin".

I even tried to guard it with an `Engine.is_editor_hint()` call but it doesn't work, I still get the same error even though line 54 shouldn't be executing:
image

Weirdly enough, this guard works fine in other parts of the project, but fails here.

### Steps to reproduce

Just create a script that extends `EditorExportPlugin`, and try to create an instance of it in an `EditorPlugin` script

### Minimal reproduction project

See "Steps to Reproduce"

I've experienced a similar issue with a tool script using `EditorScript.new()` or `EditorPlugin.new()`.

On running the project (F5), it gives `Parser Error: Native class "EditorScript" cannot be constructed as it is abstract.`. The same call works in editor.

4.0 rc2, Win x64, Forward+

Can confirm that it happens in 4.0 rc**3** as well.
`EditorPlugin.new()` works fine in the editor itself. But running the project will raise an error.

Still an issue with 4.0rc5.

It looks like #70700 added that check, which happens while analyzing the gdscript, so `if` guards don't matter there.

I'm still experimenting, hoping I can find an easy fix or workaround...

Ah: URL

You can't instantiate any editor code while running.

I don't know think the problem is not allowing editor or "abstract" code to run while the game is running. I think the problem is considering `EditorExportPlugin` as an abstract class.

I mean, `EditorPlugin` works just fine when added as an activated plugin, and I don't get why `EditorPlugin.new()` would be used, creating an `EditorPlugin` instance that isn't added as a plugin doesn't make much sense as godot will not know how to use it, so the abstract error makes sense. But why doesn't `EditorExportPlugin` work?

To customize any exports through plugins I need to:
- Be inside an existing and activated `EditorPlugin`
- Create an instance of a script that extends `EditorExportPlugin`
- add said instance using `EditorPlugin`'s `add_export_plugin()`

The above will ALWAYS make problems with running the game, even though it is the required steps to make it work for filtering exports. This is what makes no sense to me, not the abstract class thing.

In 3.x I could just do the same steps above and run the game just fine. I think this is a regression #73525, and `EditorExportPlugin`, despite it's name, shouldn't be considered an abstract class, or should be allowed somehow.

See #74025 - the check is trying to use `!can_instantiate` to infer whether the base class is abstract. But due to the check mentioned above, that fails for EditorExportPlugin (and any other API_EDITOR code).

So `EditorExportPlugin` isn't actually an abstract class? it's just being misinterpreted as one?

I had looked at #74025 but I guess I didn't understood what it was doing, so I got confused by how it would fix the problem which led to the comment above.

Right, it's registered as a normal full class: URL

But the recently added gdscript analyzer check which tries to determine if a parent class *is* abstract, instead only checks if it can be instantiated *right now*. The fact that editor types can't be instantiated when running the project leads to the analyzer incorrectly interpreting them as being "abstract".

I have this problem too:

gdscript
static func create_open_file_dialog() -> ConfirmationDialog:
 var d
 if Engine.is_editor_hint():
 d = EditorFileDialog.new()
 d.file_mode = EditorFileDialog.FILE_MODE_OPEN_FILE
 d.access = EditorFileDialog.ACCESS_RESOURCES
 else:
 # Duh. I need to be able to test it.
 d = FileDialog.new()
 d.file_mode = FileDialog.FILE_MODE_OPEN_FILE
 d.access = FileDialog.ACCESS_RESOURCES
 d.resizable = true
 return d

I was using this in Godot 3 so I could test my plugin UIs with F5 like regular "game scenes", but now Godot 4 complains of the only presence of `EditorFileDialog` even if the code never reaches it.

Meanwhile, a workaround:

Casting the `EditorExportPlugin`-derived class to a `Variant` seems to trick the compiler:

 if Engine.is_editor_hint():
 _exporter = (GitVersionInjector as Variant).new()
 add_export_plugin(_exporter)

Presumably this would also work with other classes that might have this issue.

Ran into this issue extending EditorNode3DGizmoPlugin so can confirm it works with that too.

EditorDebuggerPlugin seems to suffer the same issue and the same workaround

@chrisb123 are you trying to run a scene of the plugin? Or just your game? (If the latter it doesn't make any sense)

I'm using the example from the official documentation found here.
[( URL

I cant find any other information on using the editor debug plugin. I get the same error mentioned above and applying the fix found above does result in the debugger getting an the custom debug plugin tab
`_exporter = (GitVersionInjector as Variant).new()`

Oh sorry, I thought you were using the GDScript addon of the same name.

So the issue here is that user scripts end up trying to access Editor-only classes at runtime?

In my project, I'm not actually accessing the Editor-only classes during game runtime. However, my scripts are still loaded/parsed, and the compiler complains about it. The script code is never executed.

At least, this is what I believe to be happening, based on the fact that casting the Editor-only class to a Variant fixes the compile error, and there are no further errors during runtime.

If there is a chance to bring the fix in 4.3?

From the documentation, it is not abstract.
This blocks me actually to develop and test the scene and often needs a restart of the Godot editor.
It also blocks me to write unit tests because the scene is loaded via a test API and not instantiated by a plugin.

If you're able please test the linked PR to help it along:
* URL

I had never built the Godot binary yet, I need first to setup my environment ...

So after a lot of investigation, I find out it was a local firewall Comodo issue ... what the hell

I build Godot rebased on master and run the example project

EditorSpinSlider.zip

The parse error `Parser Error: Native class "EditorSpinSlider" cannot be constructed as it is abstract.` is gone but the components still not usable in a testing scene as described in URL

It produces errors
image

@AThousandShips what would be the next steps to move forward here?


Question: Sam's Thesis Meeting | Dec 19, 2023 - VIRTUAL?

Yes, the natbib style for citations is nice because it contains some useful information (author and year) right where the citation is located. It is a good idea if you have a file for a paper that you use the same naming convention. It does help with traceability. That is what I've tried to do in the pub repo. I slipped a few times, but most of the files have natbib style names.

If there are files that would be helpful for @JacquesCarette and me to read, it is a good idea to put the paper somewhere, or link to its public version, when that exists. For files that don't have a public version you can't put them in a public repo, but you could put them in a private repo, like the pub repo mentioned above.

Sam's Thesis Meeting | Dec 19, 2023 - VIRTUAL
My main work this week has been filling in my glossary with information I have already documented. If you think a "peer review" would be beneficial, I'm good with that! There are also some gaps to be filled in later that we could discuss if any stand out. I have some specific questions below, which will likely be answered with time and more research, but figured it wouldn't hurt to provide them to potentially get the ball rolling!

1. Level of granularity
 1. Data Testing
 2. Reviews
 3. Path Coverage
 4. Mutation
 5. Regression
2. Parent relations
 1. Regression testing: can be white- or black-box, so child or both or N/A?
 2. Metamorphic testing: seems to be black-box for the code and white-box for the tests; is the "transparency" of the testing defined in relation to the test subject?
3. Confusion on terms
 1. Data testing vs. data coverage in Patton2006 (the same thing, or testing = black-box and coverage = white-box?)
 2. White-box testing (structural analysis/testing) in Patton2006 vs. structural = white-box in other places (see also #1)
 3. Black-box testing ("specification"/functional testing) in Patton2006 vs. black-box in other places (e.g., "functional testing" for FRs)

Thank you @samm82 for preparing for our meeting tomorrow. I had a quick look at your glossary. It is good to see you working on it. A few questions come to mind. I think some of them overlap with your questions above:

- what is the methodology you are employing to make sure that you don't miss any terms?
- what does it mean for a method to be a parent of another method? Are we sure we will have a hierarchy?
- did you make any progress on the papers we discussed last week? Did they have any methodologies or results that we can borrow?
- will there be another document besides the glossary? We talked about tracking other data for the types of tests, like the required inputs.

Brief answers before I go to bed (we can elaborate tomorrow):

- Right now, I was essentially just moving all my previous research into this new format. Going forward, I am planning to revisit the sources (I think there are about 5 left to do; I've already gone through Patton2006) and keep track of "duplicated" information (e.g., definitions that are present in different sources) or "conflicting" information (e.g., a term being used to describe two different things). Then, I'll continue following more papers to see what else is out there, including their sources and papers that source them; not sure how to do this "completely".
- A child of a technique is essentially a "refinement" of it (an obvious example is that "static black-box testing" is a child of "black-box testing"). I am not sure how useful this information would be, but figured it may be nice information to track to get an idea of how the literature "hierarchs" them and could provide a column to sort this glossary by in future.
- I haven't yet gone through the papers we discussed previously (or the "glossaries" Dr. Carette provided previously, which I'll likely do first), but as mentioned above, they are coming up on my to-do list.
- Yes, eventually there will be another document beyond this. The format, information, and scope are yet to be decided; my initial thought is that this document could be "filled out" as we uncover patterns/ambiguities to be more like the original vision for this work and that it would grow over time (which would also be a nice way to work on it incrementally), but we can discuss this more.

The main takeaway here is to figure out/record my methodology. It is likely worth it to describe my ad hoc approach at the beginning (starting at well-known books within the McMaster context) but then outline the "switch" to start from more "established" resources (e.g., IEEE, SWEBOK) then "snowballing" to other resources. Of course, I should also look into other methodologies to see if there is something out there that would be a better fit.

To make sure that this isn't redundant work, we should make _sure_ that this hasn't been done. I realized that "survey" is a good keyword to search for this kind of work that I didn't look for before (I mainly focused on "taxonomy" and "ontology"), but if I am unable to find a satisfactory one, reaching out to SE.StackExchange might be a good idea. As far as learning about other techniques (and capturing as many as we can!) goes, looking into the papers from our last meeting (#15) and asking ChatGPT may be good next steps.

A minor note: Dr. Smith pointed out that it would be nice to reserve the word "formal" to refer to "formal math", so changing "formal reviews" to "structured" or "systematic" reviews may be nice. Obviously, we should record what the literature uses, but this is something to keep on the back burner for now, and to record so I don't forget!

I expanded on my methodology in 6a343eb; the bit about "snowballing" or finding other sources isn't really captured yet

Sam's Thesis Meeting | Dec 12, 2023 - VIRTUAL
Structure of glossary:
1. How should sources be captured? Should it be a LaTeX table?
2. Should the "outcome" of the test be captured at this point, or would that be getting too granular? (See point 4. below)

Review of research on existing ontologies. **NOTE:** You don't need to read the following papers/excerpts for the meeting (although you can if you want); I just want to highlight where this discussion will come from and keep track of it until I upload the papers!

1. Relations between software testing concepts (Barbosa, 2006, p. 2) 1
2. Questions from ROoST (Souza, 2017, pp. 8-9, 12) 1
3. Term for "intervention" (Engstrom, 2015, pp. 1-3) 1 : is it useful? Does it apply to methods like using oracles/equivalence classes?
4. "Test factors" vs. "Results of Testing (Area of Confidence)" column (Perry, 2006, pp. 40-41) 1 ; revisiting from #14 but actually writing down our discussion 😅

 1 I'm assuming it would be helpful to upload resources used to my repo somewhere? In a `papers/` folder, named like the BibTeX references for them? I'm sure using natbib style would also help with traceability (#7).

@smiths If there are some papers that are public and some that I've had to request access to on ResearchGate, would it make sense to store all related papers in a pub repo so that they're in one place?

It is fine to store publicly available papers in your repo, but I find that I don't do it. I keep a bib file (References.bib) in my publications repo. If there is a public link it is stored with the reference.

It looks like email notifications are set up on an individual basis. Would you like to be signed up for them as well @smiths?

## Formatting
The format of the glossary should be trivial to parse and easy to add to. CSV probably makes sense for its flexibility, and using natbib will allow for an unambiguous traceability to sources. I should make a private GitLab repo for publications so they are all in one place and named consistently. If possible, publicly available sources (e.g., Google Scholar) should be found, but if the only way to get access is through McMaster or through requesting it, it's private.

## Test Factors/Area of Confidence
The test factors from Perry might not be complete, independent, or comprehensive, but they may be useful as part of the "area of confidence" analysis; regardless, this is something to potentially return to. For now, either this "area of confidence" (or software quality, as I've been implicitly using it!) information can be left to the analysis phase, or recorded in these "simple" terms as a reminder to go deeper in the analysis phase

## Research
I should be looking "forward" to see if any resources (particularly ROoST) have been cited in more recent works! I should also be doing an "active search" by writing down what I do and what process(es) I use. For example,
- realizing that making this glossary is a "subsubtask"
- following citations (e.g., [1] from Engstrom)
- "looking forward", as mentioned above

Regardless, we noted that the notion of "intervention" from Engstrom likely isn't useful to us (or, at the very least, is out of scope) since it is too meta. I wondered about how it related to equivalence classing, but Dr. Carette pointed out that it is still a "live question", since it is something that could be generated, and isn't just an out-of-scope process for designing test cases.

Nice summary of the meeting @samm82 and yes, please add me to email notifications as well.

Closing since this meeting has occurred and items are either in progress or to be revisited later.