[PrintAsObjC] Disable -Watimport-in-framework-header warning in generated headers

This is a new warning in clang when you use @import in a framework header. That’s often a mistake, but it isn’t in our generated -Swift.h headers. If we’re building with a clang that supports this warning, we’ll now emit a pragma to disable it.
Fixes rdar://41552597.

@swift-ci please smoke test

@jrose-apple Okay with merging this?

Ah, yeah, sorry, those were my only remaining comments.

Thanks for taking this!

@swift-ci please smoke test and merge

@swift-ci please smoke test linux platform

@swift-ci please smoke test linux platform


Plugin Support for Custom Transformers

Since #13764 has landed, it's easy to write custom transformers. However, if I understand the API correctly, it is needed to duplicate the whole tsc command line just to add a single transformer. This leads to incompatibilities since these, on typescript depending, applications do not support the same features as the tsc command line tool.
It, therefore, would be favored to have a plugin system that allows loading Custom Transformers from third party node modules as this is the case for the language service proxies #12231. These transformers then easily integrate into existing build tools / build workflows.
If someone experienced has inputs on how to implement the changes, I'm willing to create a PR as it would simplify my project tremendously.

We do not plan on exposing compiler plugin system in the short term. The transforms are exposed as part of the public API as you noted, and we are in the process of writing documentation and samples for these.

I don't want to have an exposed plugin API. Instead, I would prefere way to register my custom transforms by just specifying them in the tsconfig.json instead of having to use the TS-Compiler API. Because using the TS-Compiler API implies that I can no longer use the tsc command line tool which further can imply that it does no longer integrate nicely into existing build tools and workflows.

anything update about documentation and samples ? @mhegazy

@MichaReiser you can write a simple compiler based on the API (sample here). We actually use TS very heavily within Yahoo Finance and the transformer public API have been awesome.
Those are some of the transformers we wrote after it became public:
https://github.com/longlho/ts-transform-system-import
https://github.com/longlho/ts-transform-img
https://github.com/longlho/ts-transform-react-intl
https://github.com/longlho/ts-transform-css-modules-transform
@mhegazy lmk if you need help documenting/gathering samples

@longlho
Thanks for your sample.
That is what I'm currently doing. However, it makes it impossible to use other build tools created for typescript, e.g. web pack loaders, jest loaders. Besides, how can I use one of your plugins together with one of mine when each of us uses a different frontend?
Therefore, I do believe that the current approach is a good start but not sufficient for a plugin ecosystem. Because using a plugin is too much effort for the user and requires more than just writing the transformation code for the author.
I believe a plugin system like the one of Babel is essential for typescript if the goal is to encourage the community to create and use custom transformers.

@MichaReiser yup. I'm not saying it's sufficient for the ecosystem, just good enough for the 1st step towards it.

I'd like to add support for transforms in gulp-typescript, but I want to prevent that all TypeScript plugins (for gulp, webpack etc) propose a different API. And TypeScript might add even a different way for configurating this later on. So do you currently have plans to add this in the near or far future?

Hi all, I try to write a preprocessor, but nothing comes out :[
In fact, I have two questions:

How to create AST-fragment from string?
How to add import?

// 1. Input
class Foo {
    templateString = 'some value';
}

// 2. After transformation
import __LIB__ from '@external/lib';

class Foo {
    templateString = (function compiledTemplate(deps) {
        // ...
        return result;
    })({lib: __LIB__});
}

// 3. Expected result
var lib_1 = require("@external/lib");
var Foo = (function () {
    function Foo() {
        this.templateString = (function compiledTemplate(deps) {
            // ...
            return result;
        })({ lib: lib_1 });
    }
    return Foo;
}());

A Simplified Example: https://github.com/RubaXa/typescript-api-questions/tree/master/import-add

⬆               ⬆                ⬆
@longlho, @mhegazy Can you give any hint?

@RubaXa Since you added the import declaration in a transform, it isn't bound or type checked. Since it wasn't bound or type checked, we cannot resolve __LIB__ in your expression to the __LIB__ in the declaration.
One option is to use a namepace import instead of a default import, so that your emit is something like:
import * as __LIB__ from "@external/lib"

As there is no aliasing that can occur.
The other hold onto a generated identifier for the import declaration, as per the attached zip

@RubaXa if your goal is to pass in the entire module object, you probably want to use the import * as __LIB__ from "@external/lib" syntax (which does not require aliasing) and not import __LIB__ from "@external/lib" as the latter imports the default export rather than the entire module object.

yeah we're doing import * as foo in our CSS modules transformer as well to prevent aliasing

@rbuckton O, thanks a lot!
Still interested in how to create an arbitrary AST-fragment from string?
function createFragmentFromString(code: string) {
  // ????
}

function visitPropertyDeclaration(node) {
	if (ts.isIdentifier(node.name) && node.name.text === "templateString") {
		// ...
		return ts.updateProperty(
			node,
			ts.visitNodes(node.decorators, visitor),
			ts.visitNodes(node.modifiers, visitor),
			ts.visitNode(node.name, visitor),
			ts.visitNode(node.type, visitor),
			createFragmentFromString('(function compiledTemplate() { /* ... */ })()')
		);
	}
	return node;
}

This is what i was hoping the transformer support and workflow would behave like in TypeScript.
https://www.dartlang.org/tools/pub/transformers

I am also very much interested in this feature.
as @MichaReiser  mentioned
If someone experienced has inputs on how to implement the changes, I'm willing to create a PR as it would simplify my project tremendously.
love to see inputs from experts/typescript compiler DEV .

I think this is something that could land into typescript 2.8 release, @ahejlsberg @mhegazy @DanielRosenwasser what do you think? In this way custom transformers might be more popular and therefore more powerfull. Having option to plugin in transfromer from tsconfig.json perspective would simplify life a lot.

We have no plans to expose plugins in the short term, as noted earlier.

@mhegazy Is it a considered decision or is it out of scope just because of low community interest?

I did not say that. we would like to maintain a small public API/maintainability cost as well as flexibility in changing how the build is driven moving forward, and these both are affected by a plugin model.

Please, stop transformer plugin api fragmentation. Stabilize plugin api on top of transfomer api and expose them in tsconfig.json.
ts-loader, parcel-plugin-typescript, rollup-plugin-typescript2, ts-transformer-keys, ttypescript and others.
Each of them provides custom plugin registration method and custom plugin entry point format.

Now  cevec/ttypescript supports all common transformer plugin formats. It's a drop-in wrapper on top of all typescript modules and tsc, tsserver commands (just small runtime ts.createProgram patch). Webpack ts-loader and rollup-plugin-typescript2 can be easily configured with ttypescript.
TTypescript suggest universal transformer plugin format, but existing transformers supported too.
{
    "compilerOptions": {
        "plugins": [
            { "transform": "ts-transform-graphql-tag" },
            { "transform": "ts-transform-css-modules", "type": "config" },
            { "transform": "ts-nameof", "type": "raw", "after": true}
            { "transform": "./transformers/my-transformer.ts", "someOption1": 123, "someOption2": 321  }
        ]
    },
    "exclude": ["node_modules", "transformers/**/*"]
}

Any news on this one? Seems to me like TypeScript authors somehow don't want to allow custom transformers on vanilla TypeScript - that's a shame, it would be an awesome feature.

they don't want another api/surface to maintain for fear of leading to difficulty breaking things in the internals. Ironically, all these 3rd-party plugin solutions are, because there is no standard by the ts-team,  all somewhat different and will break eventually.

they don't want another api/surface to maintain for fear of leading to difficulty breaking things in the internals.

After 3 years working with typescript and watching its evolution, I have come to a simple conclusion. Microsoft has open-sourced Typescript in the sense of the code, but not in the sense of the process. In the majority of the cases, open-source projects are more or less community-driven both in the decisions and in the coding, and this should be the natural way to evolve. Do you remember the IO.js fork of node.js? The community realized that the company interests were not so aligned with the common open source governance model, and they simply forked. I hope this won't happen for TypeScript, but Microsoft should take into account this possibility.
To be clear, I'm not blaming the devs, anyway, they do a great job, really.
Just my 2c, sorry for the OT.

Microsoft has open-sourced Typescript in the sense of the code, but not in the sense of the process.

I wholeheartedly disagree with this.  I have never worked for Microsoft, but I have had direct influence on several features of TypeScript over the past 4 years. I was representing an open source library built in TypeScript, and we arranged to have some direct conversations, but all of the "debate" of any features was done open, in public, here.  The core team publishes their design meeting notes.  The only "insider" I got, representing an open source library, was an opportunity to argue my case for some features in person and get to meet the core team.  It made me realise that the team acts as a team.  One feature we talked about, Anders basically said the problem was too hard and that it would take a lot of time to chip away at it and solve the "real" problems people faced.  That was two years ago and in TypeScript 3.0 we finally get it.  But the community has a voice in the design process, but like any community, we have factured and various voices, and no team anywhere could please everyone, and if they did, TypeScript would be a really bad tool.
You also want to label the core team "Microsoft".  The core team was the least Microsoft team I have ever encountered.  They fought battles to get total control of their release cadence, after they were founded on full control of the their release content.  They also fought for openness and transparency.  The fought to move to GitHub from CodePlex.  Admittedly they aren't that unique anymore in Microsoft as several other teams have adopted their model, but they were, as far as I am aware, the ones who started it all, with the VSCode team following quickly after.
So just because the core team pick and choose their battles, stick to their Design Principles doesn't mean that the community doesn't have a voice, but as a voice we suffer from psychotic multiple personality disorder.  We are a difficult customer to serve.

My understanding is that this is the same as #16607, or would this achieve a different goal? As a very recent plugin-author myself, I'd also like to see this exposed - including through Babel.

@mrmckeb this issue is for standardizing typescript AST transformation, while the linked issue seems to be discussing whole file transformation in a very broad (undefined) scope.

I want to add my 2 cents here. Some of you may have heard about the brilliant project babel-plugin-macros. Basically, instead of having thousands of different Babel plugins, there can be the only one which is then powered by a user code to do a transformation. An awesomely transparent system without a need to mess with configuration all the time.
Today I've opened the discussion on how to possibly get this to TypeScript world. If you have some insight, please do come and share.
Ultimately, I hope that if we somehow succeed, there won't be a need for this as only one transform will be necessary.

they don't want another api/surface to maintain for fear of leading to difficulty breaking things in the internals.

After 3 years working with typescript and watching its evolution, I have come to a simple conclusion. Microsoft has open-sourced Typescript in the sense of the code, but not in the sense of the process. In the majority of the cases, open-source projects are more or less community-driven both in the decisions and in the coding, and this should be the natural way to evolve. Do you remember the IO.js fork of node.js? The community realized that the company interests were not so aligned with the common open source governance model, and they simply forked. I hope this won't happen for TypeScript, but Microsoft should take into account this possibility.
To be clear, I'm not blaming the devs, anyway, they do a great job, really.
Just my 2c, sorry for the OT.

I agree. It is clear that despite strong interest from the community, devs are simply rejecting the idea of custom transformers/macros without actually providing a reason for the rejection except something on the lines of "People will misuse it", which also sounds offending towards the community as it implies it is a community of low quality devs.
I would accept a rejection if a reasonable justification other than "We won't simply do it" could be provided, but it seems despite all the requests from the community nobody has yet took the effort to provide that.

I think this is unfair criticism @pietrovismara. I agree that this is a must-have feature, but this isn't "Microsoft" blocking this feature. The team, as I understand it, are saying that this is not easy to support and that's why they haven't added such a feature yet.
Again, I want this feature as much as anyone else - but we need to discuss this issue using facts. The facts are that the team aren't ready to support it yet. So let's keep voicing interest, but also keep the conversation on the right track.

@mrmckeb If that's the case I can understand it. I must have missed such a declaration in the big stream of comments contained in these issues then. Didn't mean to offend anyone, just trying to provoke a clear answer from mantainers in order to, as you said, keep the conversation on the right track.

It's OK, it's frustrating that the support for this doesn't exist - as I said, I feel it, and we're asked for some kind of solution for CSS modules all the time at CRA now that we have TypeScript support. I hope it'll come soon, but I also understand that it opens up a huge area of risk for the team.

... still waiting :(

yep, still waiting ..., but waiting for what, is something been done ?

Is there any better solution than ttypescript now?
Are TypeScript developers eventually planing to support plugins?

You can create you own compiler ;-)

Any news on the topic? It seems to me that the community has made use of this feature extensively enough to sit, collect feedback, and finally add support for transformers to the config file. There are even plenty of implementations to use as reference.

It has been over 2 years (wow!)*. Are people open to a rethink of the pros and cons to opening up plugins for transformers?
I feel like the initial concerns that existed all that time ago, such as a lack of documentation about the API, and having to support the meshing of usercode <-> transformers <-> API, are not as relevant anymore. Open plugin support has worked wonders for packages like babel: progression through collaboration. I can personally attest to Babel specifically, having used it extensively.
Easier "just works" integration of transformers like typescript-is would be nice.
I think a conversation about the pros and cons would help dispel any dejection or differences on this. I get a feeling that this zombie-issue will keep on going until such happens - to be honest.
* And in the meantime someone creating the feature for TS instead (ttypescript). I've used this to success.

@DanielRosenwasser I saw that there was "Investigate TypeScript plugin APIs" on the 3.5 iteration plan (and that work has already started on it).
Does that point handle about what's discussed in this issue? The lack of a link to an issue makes me assume it's too much WIP to share anything about it yet?

I think work should be put on adding full support for Babel parser, that includes adding necessary features for Babel to support Typescript static analysis (e.g. multiple file transforms or dependency on multiple files during transformation). Rather than having to duplicate syntax/transform Babel plugins to Typescript equivalents.

here is a workaround (that takes advantage of tslint code fixing capabilities)
the following steps are for windows users only, if you are not, may god help you:

start you VSCode
install the following extension: https://github.com/Microsoft/vscode-typescript-tslint-plugin for your vscode
close your VSCode
go you some folder of your choice
run `git clone'
go to code-gen: cd ./code-gen
run

1-install.bat
2-build.bat
3-install-some-more.bat
4-try.bat

observe an instance of VSCode opened

go to test.ts (Ctrl + P -> test.ts)

observe squiggly line under @gen<Data>()

pick Quick fix... -> Needs a rewrite, fix it?

observe generated code:

@zpdDG4gta8XKpMCd, thanks for sharing your concept - but please be civil.

given the sheer negligence of the design team, here is a workaround

This is not the appropriate way to address the TypeScript for not implementing a feature that you (and many others, including myself) would like to have. This isn't a major defect, and is not reflective of "negligence". Please be respectful.

oh please do not take it personal, this is just the way i always start my complaints, i have a very sour personality (medical condition) and this is the best i can squeeze out of myself, i am very sorry

you people are not going to stop surprising me

what you see is a piece of code that seems capable of solving a major today's problem with comfort (no tricks, no hacking)
this workaround is a wake up call to the design team, and as we saw it happening before when the community was about to take a turn in a wrong direction, the design team was there to promptly addressed it: #4212,
so if they care, they can do it right rather sooner until it's too late, or if they don't, we are free to dig in this direction and it won't be a problem for them down the road
so the tone of my feedback was something inappropriate, but all the appropriate tone of yours has got you nothing since March 2, 2017 (over 2 years), and yes, you can wait another 2 years

@zpdDG4gta8XKpMCd What have you contributed towards an actual implementation? TypeScript is open source; I have no doubt they would seriously consider a pull request if you created one (even partially).
Blaming your rudeness on a medical condition is unacceptable; they are words that you typed and voluntarily chose to click "comment". No medical condition makes you do that. Speak, maybe, not type. You also have had the chance to edit your comment to remove it, yet you have not done so.
If you need custom transformers now, you can use Babel. It can remove type annotations from almost all TypeScript, while allowing syntax transformations as readily as you please. As a bonus, it's also faster.
I suggest you stop commenting before you get kicked from Microsoft's repository permanently. I know if it was my repo, you'd be on your last straw.

ok, you kicked me out, then what
can i ever come back? can i create a new account?
do you think i care about this account too much?
anyway, yes, i tried pull requests, unfortunately it's not feasible for the following reasons:

there is a certain category of problems you are welcome to solve, that are rather trivial and of less interest, anything serious like this - and your are not

since you cannot solve it on your own, a problem like this (even having 224 thumbs up) can wait for years if ever considered at all

luckily you can do something today using whatever means you have and start making a difference that can be seen, hence the suggestion (don't blame me for doing nothing)

@zpdDG4gta8XKpMCd as much as you know I've been a fan of the cynical takes over the years, I've gotta agree with others here - we need to keep the conversation civil and respectful. It's always good reminder that everyone tracking this issue wants to make the project better.

@Janpot Yup, it's very much a WIP, though when @rbuckton gets back, he may be able to give some more details on status.
As we investigate plugin points (like I alluded to in the 3.5 iteration plan), I think exposing easier hooks for custom transformers is a major scenario we want to consider. The reason we wouldn't necessarily just do this outright is that we might have broader work that subsumes this. In other words, maybe there's something broader than just pre- and post- transformers.

@DanielRosenwasser there is not that much cynical in it, i only said 2 words and then i said i am deeply sorry about that
anyway, point is i think we all agree that there is a good part of healthy frustration over how things go, and we do not blame it on you, we understand what drives this project
but if we look at it from our angle there must be somebody to blame, because letting issues like this sit over years just collecting thumbs up, is what stops from being more productive
so i guess i am referring to this conversation: https://github.com/Microsoft/TypeScript/issues/30696#issuecomment-478799258

Having thumbs ups doesn't create new resources out of thin air, make complex and difficult decisions simple and easy, change existing business priorities, stop in-flight projects, deprioritize other work, cause overly-ambitious proposals to become well-scoped, or alter a suggestion with wide-reaching and permanent impacts to become focused and maintainable.
I have no apologies for us doing (or allowing PRs for, which is what you were complaining about in #30696) upfront well-understood good and simple work ahead of extremely complex and high-maintenance work like this. It should not be hard to guess why we're willing to let someone come in and fix a leaky faucet while the plans to remodel the basement and add another story on top of the house are still being worked out.

@zpdDG4gta8XKpMCd Why would you need to blame somebody? Why don't you blame yourself in the first place that you haven't made a PR to fix this problem in the first place? Or at least some constructive write up on how to approach it from an implementation point of view?
Oh man, even after that transparent write up you just linked you have decided to poke the bear again after only 2 weeks? Try to imagine to be in that position having 1500+ tasks at hand and you have to pick a couple of those. On our team, we are moving around 100 tasks and struggling fairly enough. Cannot imagine it would 15 times more 😮

@FredyC for god sake, look at my workaround before saying i am not doing anything
yes, i am not doing formal pull requests because:

i am not up to the level for making a good one

for simple ones, there is a long line of approval, and it takes tremendous work to keep a pull request created 2 years ago up to date with the current codebase, i don't have that much time

certain problems will not be even considered, given the grand design considerations of which only few people like anders hejlsberg aware

you cannot take away the frustration part, and i am not alone here
we know there are these factors at play:

grand design of the language
budget / resources / politics inside MS
wishes of the community

i would be happier if the decision making with the mix of these ingredients was a bit clearer
i am done, it's gone too far, sorry for everyone who got their feelings hurt, i won't say a word

another option is to use function declarations themselves as markers, what's below is an implementation of a code generator for functions whose names start with toRandom...
the information source for the generator the result type of a function
this is how it works:

notice the squiggly line under a function that starts with toRandom...

explore your options:

do a quick fix

observe the results:

here is the code of codeGenRule.ts that does it
import * as Lint from 'tslint';
import * as ts from 'typescript';

export class Rule extends Lint.Rules.TypedRule {
    public applyWithProgram(sourceFile: ts.SourceFile, program: ts.Program): Lint.RuleFailure[] {
        return this.applyWithWalker(new Walker(sourceFile, this.getOptions(), program.getTypeChecker()));
    }
}

class Walker extends Lint.RuleWalker {
    constructor(sourceFile: ts.SourceFile, options: Lint.IOptions, private checker: ts.TypeChecker) {
        super(sourceFile, options);
    }
    public visitFunctionDeclaration(node: ts.FunctionDeclaration) {
        const checked = check(node, this.checker);
        if (checked !== undefined) {
            const [node, message, fix] = checked;
            this.addFailureAtNode(node, message, fix);
        }
        super.visitFunctionDeclaration(node);
    }
}

function check(node: ts.FunctionDeclaration, checker: ts.TypeChecker) {
    const { name: identifier, type: result, body } = node;
    if (body === undefined) return;
    if (identifier === undefined) return;
    const { text: name } = identifier;
    if (!name.startsWith('toRandom')) return;
    if (result === undefined) return;
    const type = checker.getTypeFromTypeNode(result);

    // if you got to here, you are at the right place and you have a type

    // working on a fix
    const properties = checker.getPropertiesOfType(type);
    const newerBody =
        `{
    return {${properties.map(prop => {
            const { name } = prop;
            const type = checker.getTypeOfSymbolAtLocation(prop, node);
            const typeName = capitalize(checker.typeToString(type));
            return `
        ${name}: toRandom${typeName}(),`;
        }).join('')}
    };
}`;
    const olderBody = body.getFullText();
    if (areEqual(olderBody, newerBody)) return;
    const start = body.getFullStart();
    const end = start + body.getFullWidth();
    return [
        node,
        'Needs a rewrite, wanna fix?',
        Lint.Replacement.replaceFromTo(start, end, newerBody),
    ] as const;
}

function areEqual(one: string, another: string) {
    // AB: we cannot make any assumption what line endings are,
    // this is why we compare the text of code without them
    return one.replace(/\r\n|\n/g, ' ') === another.replace(/\r\n|\n/g, ' ');
}

export function capitalize(value: string): string {
    const length = value.length;
    if (length > 1) {
        return value.substr(0, 1).toUpperCase() + value.substr(1);
    } else if (length > 0) {
        return value.substr(0, 1).toUpperCase();
    } else {
        return value;
    }
}

@zpdDG4gta8XKpMCd I believe this issue was more about having an easier way of plugging in custom transformers while emitting? Ex. specifying transforms in tsconfig.json rather so they can be used with tsc rather than using the api. Are you wanting custom code changes/fixes in the editor?
I haven't used them at all, but I think what you're talking about might already be possible with a language service plugin (I think by proxying getCodeFixesAtPosition on language service and inserting your own code actions... not sure though) https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin
Or maybe I'm misunderstanding?

right. that's exactly what i used to think
i thought that a way to specify my custom transforms via tsconfig.json would be a dream came true
but then later i realized like my workaround even better
here is my line on thinking:

i needed a pluggable configurable code generator
typescript doesn't have anything like that handy
on the other hand i know that tslint (although being depreciated by the end of 2019) is a decent plugin platform to typescript that has a way to configure and plugin your code with great freedom
turns out it has all i need, it is

pluggable and configurable
with all necessary UI
it gives you API to typescript
it has a few little extras

given all that i cannot see myself writing something that uses the typescript language service, because:

my laptop can only hold that many typescript language services, and some of them already are:

one by of vscode
one by tslint
i don't want to add another one on top

i wish i had a better way of plugging in my code transformers, but we have what we have

my laptop can only hold that many typescript language services, and some of them already are:

one by of vscode
one by tslint

@zpdDG4gta8XKpMCd I believe everything should be using the same language service. So you'll have a single language service and then the tslint plugin along with your plugin will proxy that.
Btw, what you're trying to do here should definitely be possible with a plain language service plugin because that's what done here.
Anyway, let's try to keep the conversation in here on topic and only about custom transformers as part of the build with tsc rather than editor code changes/language service stuff. Most people are looking for a solution to do a transform across an entire project and doing that within the editor is not a viable solution. Ideally what should be implemented here should have nothing to do with the editor/tsserver or language service.

thank you for valuable input, i will consider it
i disagree with you on keeping the conversation only about custom transformers as part of the build with tsc, since

the original request as written is not specific in which form transforms to be delivered, it only states they should not require having to

duplicate the whole tsc command line just to add a single transformer

over 2 years this discussion has drawn quite a bit of attention from many people who don't seem to care that much of the details of how transformers are implemented, provided there is a solution, it works and it's easy to use
also, we all agree that even if transformers ever find their way to the language it's not going to happen any time soon, but people here (including myself) need it yesterday
lastly, since there are not that many better alternatives, why won't we consider at least what we have?

if you insist we should do it elsewhere, please speak up

but to address your very concern of doing a

transform across an entire project
tslint does exactly that with its --fix argument for cli

@zpdDG4gta8XKpMCd --fix will update TypeScript code in place. This issue is about doing transforms during emit (so the changes only end up in the final JavaScript files). See the referenced issue's PR (#13940):

Since #13764 has landed, it's easy to write custom transformers. However, if I understand the API correctly, it is needed to duplicate the whole tsc command line just to add a single transformer. This leads to incompatibilities since these, on typescript depending, applications do not support the same features as the tsc command line tool.

In other words, that issue brought CustomTransformers (click that link and see where it's used in the API), but in order to use them tsc needs to be duplicated somehow or wrapped, which is what ttypescript does. The second paragraph then talks about how this would be good because it would integrate nicely in existing build tools (since getting the custom transformers to use would be handled by tsc rather than different build tools doing it in different ways).
I think it would be more productive to open a new issue with your concerns with code fixes or wanting an easier way to generate TypeScript code within TypeScript code. I'm not sure exactly what those concerns are as I think a lot of it is already possible today, but what you've been discussing is how to do code fixes/actions, which seems like an unrelated subject to me.
I think the main questions to answer in this thread are what Daniel discussed—"maybe there's something broader than just pre- and post- transformers"—and what the solution to making this part of the build would look like.

you are vague
i am a person who understands and appreciates simple things
my problem is that i am dealing with a 3500+ files project of which 15% of code needs to be written by and maintained by hands whereas there is a API that can do it for me, but it's so half-baked that i can never justify my time dealing with it to get it fully baked
so when i came here i though this is the right place to talk about it
turns out there might be a quick and simple solution
bad luck people came here are to discuss some much finer matters
ok, outstanding!

Having configurable transforms out of the box would be nice. I'm trying to tackle a problem of in-code string l10n and i18n. I can leverage tools like tslint with a custom rule for extraction, but my options of transforming the code are limited, unless I use something like ttypescript, but that is problematic because the app I'm working on is an un-ejected angular app. It just forces me to add layer upon layer of build tools. With the pace of development the whole stack becomes really precarious.

We are currently developing a framework and we are currently using ttypescript in order to access type-level information at runtime, it'd be nice to have the plugins option in the official compiler eventually 😄

@longlho You created a lot of great ast transformers, I need your help please :+1:
I really would like modify decorator metadata before Angular copilation.
My goal is modify this node
Component({ selector: 'standard' ... }) into Component({ selector: 'custom' ... })
I made a github repo for test it https://github.com/gioboa/ng-ts-transformer . I think it's possibile but without documentation I need some help. :pray: Thanks.

I’m on vacation right now but will look next week when I’m back
On Sun, Jul 21, 2019 at 5:54 PM Giorgio Boa<EMAIL_ADDRESS>wrote:

@longlho https://github.com/longlho You created a lot of great ast
transformers, I need your help please 👍
I really would like modify decorator metadata before Angular copilation.
My goal is modify this node
Component({ selector: 'standard' ... }) into Component({ selector: 'custom'
... })
I made a github repo for test it
https://github.com/gioboa/ng-ts-transformer . I think it's possibile but
without documentation I need some help. 🙏 Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/TypeScript/issues/14419?email_source=notifications&email_token=AABQM335QEEDNVT4NUICJQDQASBDXA5CNFSM4DCFER5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2OGIWQ#issuecomment-513565786,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABQM33S5IYXB5HOZTRVVX3QASBDXANCNFSM4DCFER5A
.

@gioboa for future reference, please don't use the issue tracker to solicit help for programming problems—there are other ways to get in touch with people without causing notifications for everyone following this issue. Additionally, you could ask your question on stack overflow under the typescript-compiler-api tag. Let's keep everything in this thread on topic to the original issue at hand. Thanks!

I've contributed to create a library to create real mocks from interfaces without proxy . I'm recommending to use ttypescript for now but it would be nice to have an integrate way with typescript

I would really love to see this feature happen.  I'm pretty sure this is the only thing standing between Typescript and some of the greatest innovations it may lead to.

Typescript is huge contribution to frontend development, but it also has a brake on further innovation…
Do not break the semantics. No plugin ATM cannot break semantics; and no plugins are allowed at all :man_shrugging: Why?
There are really good plugins, but. Every plugin must respect (key)word tokenization and AST instation)… , really hard way to do something inside.
It's no so hard. It is no easy, but babel project show that it's possible.
In fact it is almost trivial for babel to introduce new semantics or even syntactics phrases.
I do not expect from typescript to allow semantics. (also I'm not expecting syntax changes of course! )
What I wish is from compiler is shift in some cases, like (may be only type) preeval.
Like if I have a took function, like route or message or something, compiler can preeval and (oh, please, at phase one) check correctness.
If you reading my previous paragraph weird. What is tsx and all React goodness?
No React, no flow, no typescript at all, almost not at glance.
Please. I'm well understanding careful look-standing at all this; but as we learn from IE5.5+; blocking is no way forward.
If something needs improvement, it's still layout engine. D.Knuth was guenie who designed all the missing parts 50 years ago. Why we have not this today?? :-)
Please, tell the people to stop CSS in JS evilness.
Please. Open TS for semantics intelligence; like function with static string input, providing type hint for the rest; analyse actual const input string…
A Little Example:

GraphQL call return shape
Intl input shape
…much more_
Please. No semantics changes needed. Everything will work as desired. Something more may be checked at build time. That's all folks! :rabbit:

bump

I'm experimenting with writing TS transforms for optimization core-js import - automatic polyfilling for target environments, like @babel/preset-env and @babel/runtime, but without babel. It could seriously help a big part of TS developers. But without support custom transforms from the box without additional tools like ttypescript, the possibility of using those transforms will be seriously limited, so I'm not sure that it makes sense.

I've been experimenting with such an idea - https://github.com/webschik/typescript-polyfills-generator.
I think that Transformers API will open a possibility to drop babel from the development chain. I think a lot of developers do not want to use them both, but they still need plugins such @babel/preset-env.

We currently have rolled our own custom compiler script (using the TypeScript compiler API) due to this limitation. We briefly looked at ttypescript, but the appetite to  move away from the vanilla TypeScript compiler to an extension of the TypeScript compiler is simply not there.
It would be fantastic if custom transformers were supported in tsconfig.json. It's cumbersome to write a script which simply parses tsconfig, declares transformers, then runs the compiler. Other people have been echoing this sentiment, but allowing for the ease of integrating custom transformers into the compiler would take a significant load off of the TypeScript development team and allow for innovation and additional forward momentum with this language from the community.
An example of a very successful plugin ecosystem is the Serverless Framework's plugin community. The development team cannot keep up with the demand for feature development, and plugins allow for a great way to allow for the integration of new (possibly experimental) features without the need to open PRs or water down the core product with features which may or may not provide value to the broader user base.

I'm building a library and I have decorators in it that work great for me and that I depend on. I realized some time ago that decorators make my library not tree-shakable. After looking into it I came to conclusion that transformers could help me turn those decorators into tree-shakable code upon compilation. It is unfortunate that I cannot define them in my pipeline. I hope you will get to this issue soon, just wanted to drop my 2 cents on a use case where it would be very helpful.

In the interest of making TypeScript support custom transformers without wrapper programs and complicated instructions for various, I've written a tool called ts-patch (npm github)
Simply install ts-patch (globally or locally) and run ts-patch install to patch typescript. You can also specify the typescript installation directory and/or enable persistence, which maintains the patch if TS is updated or reinstalled. (details: ts-patch /?)
The patch logic is mostly based on ttypescript. (Big thanks to cevek's great work!) It's written in a way where it can easily be added to npm package install process. It's also easy to unpatch.
To be clear, this directly patches relevant files in typescript itself and is not a wrapper. Simply run the patch after dependency installation, and typescript will be transformer ready.
Hope this helps some people!

In the interest of making TypeScript support custom transformers without wrapper programs and complicated instructions, I've written a tool called ts-patch (npm github)
Simply install ts-patch (globally or locally) and run ts-patch install to patch typescript. You can also specify the typescript installation directory and/or enable persistence, which maintains the patch if TS is updated or reinstalled. (details: ts-patch /?)
The patch logic is mostly based on ttypescript. (Big thanks to cevek's great work!) It's written in a way where it can easily be added to npm package install process. It's also easy to unpatch.
To be clear, this directly patches relevant files in typescript itself and is not a wrapper. Simply run the patch after dependency installation, and typescript will be transformer ready.
Hope this helps some people!

could this be raised as a PR to add proper support? :)

Hey.  For what it's worth, there's a bundler called fuse-box which makes it very easy to add custom transformers.  Its 4.0 version is coming up soon... so it's in an in-between spot.  But overall, I really like the bundler.  Maybe it can help you too.
https://github.com/fuse-box/fuse-box/blob/master/docs/plugins/pluginCustomTransform.md

could this be raised as a PR to add/discuss proper support? :)
The TS team has expressed that they do not want to provide this as a native feature. Their reasons for the decision make sense!

The good news is that because TS is open source and is already compiled in a modular fashion, ts-patch behaves in a way very much like it would if it were built in. So it's not like a buggy reverse engineered bytecode patch.
If by support, you're concerned over it being maintained, I plan to keep it current and working for all future versions of TS! A lot of my commercial infrastructure already depends on it.
As a side note, I will be releasing a new version soon which allows for packaging multiple plugins with different entry points into a single package as well as some other optimizations.

After writing a plugin I can appreciate why the ts team are hesitant - the current transformer is a post-compile step. You run into nasty problems if you do anything complicated and start adding new content that wasn't originally binded. As it stands, ts-node --compiler ttypescript foo.ts works perfectly fine. I'd rather the ts team deal with transformer plugins at different compilation steps... or allow for a rebinding step.

The current transformer is a post-compile step. You run into nasty problems if you do anything complicated and start adding new content that wasn't originally binded.

Transformers can run either before or after TSC compilation. It sounds like what you may be referring to is that the checker doesn't update after modifying nodes. This can actually be circumvented, the functionality just wasn't built out for it. When you invoke ts.transform(), it doesn't create a full Program instance for you to work with, so if you want to work with the checker, you need to create one. Using CompilerHost, you can reload it with the modified files after altering the AST.
I haven't gotten too far into it yet, but it looks like it also may be possible to use 'watch' functionality to avoid having to rebuild the entire Program instance each time. Put simply, it turns out it's not actually too difficult to have a more complete Plugin system, but transform simply lacks the support in the context.

@nonara I've used transforms with ttypescript and ts-loader`, both have full program entry points. My problem is that if you add a new import statement, its missing "something" and those new statements are stripped out of the final output emit. @mhegazy says its because transform is a post-binding step. The only solution apparently is to make an entirely new Program for the file - but that just seems like a headache when you're dealing with things like ts-loader. In the end I dropped the import and just inlined the code I needed.

@MeirionHughes Ah, ok. In that case, yes, you do have a Program instance. ttypescript works by hooking createProgram to patch the resulting program's emit method to include the transformers.
ts.emitFiles calls ts.transformNodes during the process.
ts.transformNodes can be called with or without a Program instance. Directly calling ts.transform() does it without one.
If I'm understanding it correctly, it sounds like your issue is also tied up in the fact that the types & symbols have already been walked, and they do not get updated after AST transformation. IMO, this is a big limitation in terms of design. I offered to make a small modification to help mitigate that in cases like yours, but to be honest, I'm not optimistic at this point of getting a response.
So in order to help others and myself work around that issue (and to ensure we have accurate checker data in the case of chained transformers), I'm planning a fairly big re-design for the next version of ts-patch that takes control of the transform process and offers options for automatic or manual Program sync during transformation. I plan to also look into the watch capability to keep times to a minimum.
I'm working on wrapping up another project now, but I should hopefully have a release in the next month.

Hey everyone I've been writing up a Transformer Handbook to colocate all the information about transformers as well as to make it easier to get started.
https://github.com/madou/ts-transformer-handbook/blob/master/translations/en/transformer-handbook.md
Would love some eyes on it if you can spare a sec 👍

@madou I also wrote a buncha posts on TS transformers https://levelup.gitconnected.com/writing-typescript-custom-ast-transformer-part-1-7585d6916819

What's the status on this?

Love typescript a lot, but it feels especially clunky when you start to interop between static types and runtime JS. There are numerous community-written plugins to make this better, e.g. https://github.com/dsherret/ts-nameof, https://github.com/kimamula/ts-transformer-keys - but without first-class plugin support it feels like a risky technical decision to include them in a project. Enabling plugins natively would allow the community to play around with potential future typescript features, before they need to be included in the core library.

I think TypeScript team should re-consider their argumentation. The plugin eco-system is a proven way of moving the language forward, enabling (and encouraging) experiments (see Haskell with its pragmas).
Some of those experiments will be wild and crazy, and some will eventually stabilize and become common. Its always good to provide the ability to implement language features in the user space.
In general, the position of TypeScript team looks unnecessary rigid.

There are also transforms which don't change the language but provide additional information for better debugging behaviour.
For example the babel-plugin-transform-react-jsx-source is part of the default react transpiling preset (@babel/preset-react).
It transforms
<sometag />

Into
<sometag __source={ { fileName: 'this/file.js', lineNumber: 10 } } />

To provide a better developer experience by providing better stacktraces during development.
For typescript there is no standard way to achieve the same although there is a open source transform: https://github.com/dropbox/ts-transform-react-jsx-source

I understand @mhegazy mentioned twice that TS team has no plan of including “plugins” as part of tsconfig. What is the reasoning behind this?
Would you be open to a PR? The way ttypescript handles the transformers via tsconfig is pretty nice.
Usecases:

generating interface types to schemas so they can be runtime checked.
importing json with strings as literals so typescript doesn’t barf when assigned to a type with discriminated unions.
importing css/yaml and other object like syntax
making graphql queries that dynamically create the right types
compiling jsx to html strings so they can be innerHTML injected
rewriting absolute imports to relative imports based on tsconfig paths.

The list goes on and on. The plugin api is nice. Thanks for landing it.  Having “plugins” part of “tsconfig” makes tsc really powerful. Is there something big we’re missing ?

you can also do a lot of performance optimizations. i've been writing https://github.com/atlassian-labs/compiled-css-in-js with typescript transformers 🤙 would be cool if consumers didn't need to jump through hoops to use it though.

Dear Typescript team, please stop dragging your heels on this <_<

What's the status on this?

Status?

Friends what news?

The typescript team has decided against this idea - if you need flexibility or better dev tooling using typescript is not an option without hacks - go with babel instead and use typescript only for typechecking

The typescript team has decided against this idea - if you need flexibility or better dev tooling using typescript is not an option without hacks - go with babel instead and use typescript only for typechecking

But what if I want some hacks for type-checking? I write a little transformer that makes some magic:
type Human = {
    name: string,
    age: number
}

const isValid = check<Human>({ name: 'Carl', age: 16 }) // => true
const isValid = check<Human>({ name: 'Carl' }) // => false

Function check transformed into specific type-guard function! How I can make it with Babel? Currently, I should use ttypescript...

The typescript team has decided against this idea - if you need flexibility or better dev tooling using typescript is not an option without hacks - go with babel instead and use typescript only for typechecking

There is actually some talk of this becoming supported in the future. That said, it really is already supported. The TypeScript compiler API supports transformers, and it's really simple to write a custom compiler in a few lines of code.
But in order to make it easier, you can use ttypescript or ts-patch.
These libraries aren't really a "hacks" in the sense that they are not augmenting the compiler to add transformer ability. Instead, they simply expose the existing functionality of of the compiler to tsc, making it usable via tsconfig.

@ilya-buligin if I understand your use-case correctly, you can declare an ambient constant
declare const check: <T>(value: unknown) => value is T;

const isValid = check<Human>({ name: 'Carl', age: 16 }) // => true

Typescript will compile the code relying on check type definition and then you will replace it with a generated code using Babel.

@just-boris how I can get access to generic type  in Babel?

This thread is getting fairly repetitive and off-topic. @RyanCavanaugh Perhaps this thread should be locked, until you have any updates on the subject.

I just wanted to hop in and add another use-case.
I'm working on an application that leverages the webpack extensions config to prioritize some custom extensions over the others. So, for example, if a Hello.android.ts file exists, it will pick that up automatically when you do import Hello from "./Hello".
Right now, obviously, typescript is not very happy with it, and we have to patch our way around it by adding a Hello.ts file which exports a null value as the type of the Hello.android.ts But we really like to eliminate this part as it has become kind of a headache to write and maintain these files.
I was researching for a solution when I came up with the typescript transformers, and they just seemed like the ultimate solution for our issue.

I just wanted to hop in and add another use-case.
I'm working on an application that leverages the webpack extensions config to prioritize some custom extensions over the others. So, for example, if a Hello.android.ts file exists, it will pick that up automatically when you do import Hello from "./Hello".
Right now, obviously, typescript is not very happy with it, and we have to patch our way around it by adding a Hello.ts file which exports a null value as the type of the Hello.android.ts But we really like to eliminate this part as it has become kind of a headache to write and maintain these files.
I was researching for a solution when I came up with the typescript transformers, and they just seemed like the ultimate solution for our issue.

What do you think. Is this an announcement of the end of API for plugins?

We are 100% committed to not rewriting JavaScript code as part of non-downleveling compilation. This is how everything else in TS works

Originally posted by @RyanCavanaugh in https://github.com/microsoft/TypeScript/issues/16577#issuecomment-754941937

What do you think. Is this an announcement of the end of API for plugins?

We are 100% committed to not rewriting JavaScript code as part of non-downleveling compilation. This is how everything else in TS works

Originally posted by @RyanCavanaugh in https://github.com/microsoft/TypeScript/issues/16577#issuecomment-754941937

Is this an announcement of the end of API for plugins?

I just read the original comment and I do believe that this is related to "rewriting JavaScript code" inside the compiler as a part of TypeScript compiler itself.

Is this an announcement of the end of API for plugins?

I just read the original comment and I do believe that this is related to "rewriting JavaScript code" inside the compiler as a part of TypeScript compiler itself.

ttypescript is nearing 200.000 downloads per week: people want this.

ts-patch does the same thing - 3,451 downloads.

ts-patch does the same thing - 3,451 downloads.

Yep, more convenient to use than ttypescript. Not popular yet though.

Friends, what news? Already 2022. What are your plans for this functionality? Are you planning support in an experimental form, or have you decided not to do it at all?
Thanks!

This comment puts it at status-declined but the tags haven't been updated yet and the issue hasn't been marked closed.

@wbt I doubt anyone on the TypeScript wants to close this, because it would be a super unpopular move, and probably get a thousand thumbs down reactions.
We all want this, every single day.

The typescript team has decided against this idea - if you need flexibility or better dev tooling using typescript is not an option without hacks - go with babel instead and use typescript only for typechecking

But what if I want some hacks for type-checking? I write a little transformer that makes some magic:
type Human = {
    name: string,
    age: number
}

const isValid = check<Human>({ name: 'Carl', age: 16 }) // => true
const isValid = check<Human>({ name: 'Carl' }) // => false

Function check transformed into specific type-guard function! How I can make it with Babel? Currently, I should use ttypescript...

https://deepkit.io/library/type

https://github.com/typescript-rtti/typescript-rtti also allows for checking values against types:
reflect<MyType>().matchesValue(anObject);

...and a lot more
On the topic of bringing the functionality of ttypescript (or equivalent) into core, I hope the team reconsiders. Transformers are a way to let the community do the mutation and keep it out of core, we just could use a better DX for it.

We need this, please!! 🥺

+1

+1 Badly needed for my intended project.

Given the huge list of projects already using this, you would think it's time to put it on the roadmap. 🤔
And this list is just projects using it specifically for reflection - another neglected feature many people miss bad enough that they'll go and build their own solutions; even with no official support for building such a feature, meaning every single one of these projects "hack" this feature in somehow.
I understand the list of requested features remains huge, but these are clearly two of the most sought-after features. You would think someone on the team would take note.
If they were to officially open up the language to third-party extensions, I'm sure a lot of these features would get built by the rather large community already trying to "hack" them in without a sanctioned, stable API.

No one has mentioned yet that Angular is forking the entire typescript compiler to add AOT compilation of templates.
Angular users are, therefore, locked-in to a specific TypeScript version.
Curiously, Angular folks have put the rewrite of the Angular compiler as a TS plugin on their roadmap.
https://angular.io/guide/roadmap#improved-build-performance-with-ngc-as-a-tsc-plugin-distribution

Would be awesome if we had this in our project.
How can I check the progress on this?
would love to help out if I can.

I am looking to do some comple-time massaging of the exported types from my library so I can massively simplify its development. When investigating options I found that the tsconfig has a plugins option and though "oh good, it's gonna be easy, I just need to write a plugin", but when I looked further for how to actually make said plugin, I found this issue.
You already have support for it in the compiler API, you already have the plugins option in the tsconfig, and people have already done the work of joining the two together (just see ttypescript and ts-patch).
Would the TS team be open to PRs for this? There is enough support for this feature that we can definitely make the actual implementation happen as long as the TS team will receive it.

Please seriously consider this! There really is no harm in supporting this as far as I can see, and implementation would be very simple. All it really requires is calling each plugin during transformation!

As a developer of typia and nestia utilizing transformation, whenever there is a critical patch for the TS compiler API, the libraries break and stress me out.
Quietly vote yes and go.

When this issue was opened I was 17 years old and just started using TypeScript, this problem went way over my head and didn't understand what it was about.
I'm now 23 and been following this thread for a little bit more than 6 years. The question is: Will my kids be able to write transformers in an easy manner without depending on external wrappers like ttypescript?

bump
We need this feature

We need this feature :)

we need this feature, thanks!

The lack of an official transformer means that users will have to create and use their own.
But every time a version of Typescript goes up, the libraries suffer and need to be updated.
Among them is ttypescript, which is widely used, but whose creators don't care.
For now, we support TS@5 with the same usability via yarn add ttsc. this package
The point is that the lack of an official transformer is an inconvenience for many users and slows down the evolution of the language's ecosystem.

Hello @sunrabbit123
Your documentation shows an incomplete type declaration for the plugins:
(program: ts.Program, config?: PluginConfig) => ts.TransformerFactory;

In fact there is a third argument which is important.
(program: ts.Program, config: PluginConfig, helpers: { ts: typeof ts; addDiagnostic: (diag: ts.Diagnostic) => void }) => ts.TransformerFactory;

Passing references to ts makes the plugin completely dependency-free.
Passing callback addDiagnostic allows it to interact with the user in accordance with the compiler standard (instead of console.log).
I think it's important that authors of their own compilers and plugins maintain this standard.

@sosoba
Thank you for reporting the issue.
We'll move it to an issue for decontextualization.
Thank you.

TS 5 update is shutting down everyy transformer based libraries over a month. It's a recurring problem every time the TS version is updated, and it's too hard every time.
What are the barriers to supporting official plugins in TS? If it's because of the lack of documentation or guides for the TS compiler APIs, can I contribute this part?

Assume the answer were "yes", let's add custom transformers, ignoring all previously-presented reasons not to do it (this is a long thread I have not read in totality). Note that this issue is not "compiler plugins" (#16607) which is a massively less approachable idea compared to the very well-defined idea of "just allow extra transformers".
These are the challenges I see so far:

Adding plugin support similar to the language service plugins will prevent tree shaking in tsc.js. This will grow the file by 200KB and increase tsc's startup time by 10%. (200KB feels low; per https://github.com/microsoft/TypeScript/commit/25a85d1faa474d73176545f876e1fa58a2564706 this should be a lot more, and I'm not sure why it isn't as bad now as it was then.)
The "services" project is not included in tsc.js, so the API familiar to the users of typescript.js would not be available. This means that:

We could include the services project in tsc.js, increasing its size by another 2MB or so. This will slow things down even more, both by the size increase, but also a shift in the "object allocator" that creates Nodes/Types/Symbol/etc. IIRC, the allocators are poised to go away in the future anyway.
We could come up with a new d.ts file for tsc plugins which describes the limited API available in the core compiler. This seems more reasonable (a la tsserverlibrary), but is more complexity.
We'd need to decide if the the "deprecatedCompat" code would be in tsc.js. If we don't do this, we can't deprecate anything safely, as a plugin may depend on something we want to remove. If we do do this, then the compiler may be slowed down by the hotpatching the deprecation system does. The latter is certainly not a good idea without ensuring performance is maintained.

Like LS plugins, these plugins could only be CJS thanks to the synchronous nature of the codebase, unless we majorly restructure. "Async in TS" is a totally different ~can~ 50 gallon barrel of worms.

If it is because of the lack of documentation or guides for the TS Compiler API, would you be willing to settle it as an official specification if I help you document this part?

I don't think this is in any way blocked by documentation. If you believe there are holes in our current documentation, those would totally benefit from a dedicated issue. See also #53239.

@samchon There are valid reasons for why the team chose not to do this, many of which Jake detailed above.
Regarding keeping up with TS changes, part of the reason it took longer for me to do this time is because it was time to fundamentally change the underlying structure to make what we're doing easier. It was long overdue.
So, not only will keeping up be easier in the future, we will ultimately be adding CI to monitor dev builds. This will help us add support for new versions before they're released.
As a side note, I would like to kindly ask that people not post issues on the TS repo that pertain to ts-patch. I recognize that your comment here is more broad and applies to this discussion, so I'm more referring to some of the other posts that have been made recently.
Namely, I've been tagged a few times in complaints directed toward the TS team about changes that broke tsp. I'd like to remind everyone that the onus is on us to keep up, and Jake has been kind enough to even let us know ahead of time when big changes happen.
TLDR is - Right now, you can use beta3, which is stable. In the future, we are working to better avoid gaps between supporting new versions.

I have just filed #54276, which is a concrete / minimal proposal for closing this issue. In short, the proposal currently being evaluated simply adds the ability to include CustomTransformers (with access to Program), using configuration / an API similar to ttypescript or ts-patch.
I expect that we'll probably close this long thread at some point; it's gotten so unwieldy and large that I'm not sure that it's very useful anymore. If we do #54276, it will not preclude any new features or additional extensibility of tsc, and I think that addons can be discussed in new issues (or, if in scope for #54276, on that thread).


Support specifying priority on rich rules

Pull Request (PR) description
Adds support for the priority option on rich rules, to allow ordering them outside of the normally implicit - and not guaranteed to be deterministic - ordering imposed by when they're added.

Hi -- will this PR get rolled into a release?  Been almost 2 years, but I cannot really convert from firewall to firewalld without the ability to set a priority in rich rules...

What's the word about getting this approved and implemented?

@tskirvin there's an open comment from @trevor-vaughan that needs to be addressed :)

Fair enough, but I'm with @decibelhertz here - I can't really start converting from firewall to firewalld until this is addressed, and I'd prefer to work under the don't-let-perfect-be-the-enemy-of-good policy.

There we go, must've missed the notification about that comment.
Also rebased it onto master while I was at it adding a validation.

What's the word about getting a new puppet forge release for this change and any others that have come recently?  The last official release I see was 4.5.1 back on 15 Aug.

From what I get this feature is not available in the firewalld version that comes with centOS/rhel 7. So releasing this means the module does not support that OS-version anymore.

I also find myself needing this enhancement. I thought I might be able to use it by pointing the Puppetfile mod at the github master branch instead of puppetforge, and it does appear that I'm getting code with these changes, but I'm still getting a Server Error: no parameter named 'priority' when I try to add a priority to a rich rule. Should it work as-is, or am I missing something?


Persist state?

Could this be a consideration? Either by default or as an option?
It would mean not resetting the state when a component is unmounted?

Yeah, we could definitely do it as an option in the config that gets passed in. Can you do a PR?

In order for the UI State to persist and be recalled by name the uuid suffix should be removed when a config option of persist is true.
Happy to continue if it's worth doing, otherwise I'm happy to create a separate fork.


Node Health Checks fail with azurefiles home directories (uses nfs4 rather than nfs3)

In what area(s)?

/area administration
/area ansible
/area autoscaling
/area configuration
/area cyclecloud
/area documentation
/area image
/area job-scheduling
/area monitoring
/area ood
/area remote-visualization
/area user-management

Expected Behavior

Nodes pass the health check when there is a mount for /sched and home
Actual Behavior

The health check fails as the mount is type 'nfs4' rather than 'nfs'
Steps to Reproduce the Problem

Deploy with AzureFiles for the home directory and submit a job.

this is fixed in jupyter branch


MNT: Re-rendered with conda-build 3.20.2, conda-smithy 3.7.10, and co…

…nda-forge-pinning 2<IP_ADDRESS>.42.03

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Support vendor APIs

What is the right way to vendor APIs, like querying number of openblas threads and such? Is it possible to add all vendor API names to the library, and then set them to a function that prints an error message if that particular vendor API doesn't exist in the forwarded BLAS?

All the openblas vendor APIs are in because of the gensymbol script being pulled from openblas. Ideally, we want to keep separate files for vendor APIs so that they can be updated over time.

All the openblas vendor APIs are in because of the gensymbol script being pulled from openblas. Ideally, we want to keep separate files for vendor APIs so that they can be updated over time.

We will want to add in vendor-specific names (like openblas_get_num_threads()) which should be harmless, but we definitely want to write some generic APIs over the vendor-specific stuff so that we can, for instance, get/set the number of threads no matter whether we're using MKL or OpenBLAS, as right now it's difficult to know precisely which one we're using and you don't want to try and call the wrong one.
If we can get a list of the vendor-specific APIs that we might want, we can think about the best way to wrap them.

#19 adds the MKL APIs we need to make the entire Julia testsuite pass on MKL.

I'm going to close this one and open up specific vendor blas related issues as they pop up.


Add a link to complete examples in documentation

I've got some feedbacks that some users want to see the complete working example code for some features. In such case, the small example code in the docstrings are not enough.

Jenkins, test this please

Jenkins CI test (for commit 2eb29280f96a27cefd752f731e36eb013aaae58a, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

See also the discussion of #5388 on how to refer a code block in examples.

@toslunar OK, this PR should be fixed after #4741 is merged.

Jenkins CI test (for commit 546a6915448e4df3f92ef07d321dd1dba756a607, target branch master) failed with status FAILURE.


updated performance docs

Signed-off-by: NagaHarshita<EMAIL_ADDRESS>Description
This PR fixes #3214.
The output of the help command is taken as a reference to update the docs. Please suggest changes if any.
Signed commits

[x] Yes, I signed my commits.

Good progress, @NagaHarshita 👍  Perhaps, we should breakdown this work into multiple PRs to make it a more digestible set of changes?

@NagaHarshita The flags are under apply subcommand under perf. plus perf list is also not added.

Good catch @piyushsingariya. @NagaHarshita, do you feel that you can address these subcommands in this PR or is opening up a new PR to tie off the rest of the subcommands easier? If the latter, please open up an issue to track the need for apply and list

Good catch @piyushsingariya. @NagaHarshita, do you feel that you can address these subcommands in this PR or is opening up a new PR to tie off the rest of the subcommands easier? If the latter, please open up an issue to track the need for apply and list
I will try to complete the mentioned changes in this pr.


[Bug] Pooled client not reconnecting after redis server restart

Redis version - 7.2.1
Platform - linux
Using Docker and/or Kubernetes - yes
Deployment type - centralized
Client Version - 6.0.0
Describe the bug
After the redis server restarts, some of the pooled clients do not reconnect properly, and would stay disconnected.
To Reproduce
Steps to reproduce the behavior:

Have a pooled redis client setup
Restart the redis server

Logs
2024-01-19 15:56:45.971897 [003] [E] [module]:0508 Publisher fred-r2Vpm04xGY received connection error: Redis Error - kind: Canceled, details: Canceled.
2024-01-19 15:56:45.972125 [003] [E] [module]:0508 Publisher fred-rguEkovGiW received connection error: Redis Error - kind: Canceled, details: Canceled.
2024-01-19 15:56:45.972458 [003] [E] [module]:0508 Publisher fred-8riVj9Z1U1 received connection error: Redis Error - kind: Canceled, details: Canceled.
2024-01-19 15:56:45.972564 [003] [E] [module]:0517 Subscriber received connection error: Redis Error - kind: Canceled, details: Canceled.
2024-01-19 15:56:45.988387 [002] [E] [module]:0508 Publisher fred-OLWAIgYmt8 received connection error: Redis Error - kind: Canceled, details: Canceled.
2024-01-19 15:56:46.245854 [003] [E] [connection]:0499 fred-OLWAIgYmt8 Failed to set client name with error Null
2024-01-19 15:56:46.245853 [002] [E] [connection]:0499 fred-BrOHlVd15E Failed to set client name with error Null
2024-01-19 15:56:46.246200 [002] [E] [module]:0517 Subscriber received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:46.246586 [003] [E] [module]:0508 Publisher fred-OLWAIgYmt8 received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:46.275971 [002] [E] [connection]:0499 fred-8riVj9Z1U1 Failed to set client name with error Null
2024-01-19 15:56:46.276174 [002] [E] [module]:0508 Publisher fred-8riVj9Z1U1 received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:46.280357 [003] [E] [connection]:0499 fred-rguEkovGiW Failed to set client name with error Null
2024-01-19 15:56:46.281648 [003] [E] [module]:0508 Publisher fred-rguEkovGiW received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:46.718875 [002] [E] [connection]:0499 fred-OLWAIgYmt8 Failed to set client name with error Null
2024-01-19 15:56:46.719072 [002] [E] [module]:0508 Publisher fred-OLWAIgYmt8 received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:46.719140 [003] [E] [connection]:0499 fred-8riVj9Z1U1 Failed to set client name with error Null
2024-01-19 15:56:46.719282 [003] [E] [module]:0508 Publisher fred-8riVj9Z1U1 received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:46.726878 [003] [E] [connection]:0499 fred-rguEkovGiW Failed to set client name with error Null
2024-01-19 15:56:46.727097 [003] [E] [module]:0508 Publisher fred-rguEkovGiW received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:46.739626 [002] [E] [connection]:0499 fred-BrOHlVd15E Failed to set client name with error Null
2024-01-19 15:56:46.739750 [002] [E] [module]:0517 Subscriber received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:47.540405 [003] [E] [connection]:0499 fred-OLWAIgYmt8 Failed to set client name with error Null
2024-01-19 15:56:47.540689 [003] [E] [module]:0508 Publisher fred-OLWAIgYmt8 received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:47.582512 [002] [E] [module]:0517 Subscriber received connection error: Redis Error - kind: IO, details: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2024-01-19 15:56:47.600512 [002] [E] [module]:0508 Publisher fred-8riVj9Z1U1 received connection error: Redis Error - kind: IO, details: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2024-01-19 15:56:47.612316 [002] [E] [module]:0508 Publisher fred-rguEkovGiW received connection error: Redis Error - kind: IO, details: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2024-01-19 15:56:49.202132 [002] [E] [module]:0517 Subscriber received connection error: Redis Error - kind: IO, details: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2024-01-19 15:56:49.208920 [003] [E] [connection]:0499 fred-OLWAIgYmt8 Failed to set client name with error Null
2024-01-19 15:56:49.209168 [003] [E] [module]:0508 Publisher fred-OLWAIgYmt8 received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:49.233593 [003] [E] [connection]:0499 fred-rguEkovGiW Failed to set client name with error Null
2024-01-19 15:56:49.233799 [003] [E] [module]:0508 Publisher fred-rguEkovGiW received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:49.270152 [002] [E] [module]:0508 Publisher fred-8riVj9Z1U1 received connection error: Redis Error - kind: IO, details: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2024-01-19 15:56:52.443043 [002] [E] [connection]:0499 fred-BrOHlVd15E Failed to set client name with error Null
2024-01-19 15:56:52.443214 [002] [E] [module]:0517 Subscriber received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:52.443388 [002] [E] [module]:0508 Publisher fred-OLWAIgYmt8 received connection error: Redis Error - kind: IO, details: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
2024-01-19 15:56:52.502431 [003] [E] [connection]:0499 fred-8riVj9Z1U1 Failed to set client name with error Null
2024-01-19 15:56:52.502657 [003] [E] [module]:0508 Publisher fred-8riVj9Z1U1 received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:52.533417 [002] [E] [connection]:0499 fred-rguEkovGiW Failed to set client name with error Null
2024-01-19 15:56:52.533655 [002] [E] [module]:0508 Publisher fred-rguEkovGiW received connection error: Redis Error - kind: Protocol, details: Failed to set client name.
2024-01-19 15:56:58.901709 [002] [I] [module]:0541 Subscriber fred-BrOHlVd15E reconnected.

2024-01-19 15:56:58.918787 [002] [I] [module]:0526 Publisher fred-8riVj9Z1U1 reconnected.
2024-01-19 15:56:58.933892 [003] [I] [module]:0526 Publisher fred-OLWAIgYmt8 reconnected.
2024-01-19 15:56:58.956885 [003] [I] [module]:0526 Publisher fred-rguEkovGiW reconnected.
2024-01-19 15:56:58.956929 [003] [I] [module]:0528 All publishers reconnected. <--- redis.clients().iter().all(|c| c.is_connected())

2024-01-19 15:57:05.395715 [002] [E] [module]:0593 Failed to ping redis server with Timeout Error: Request timed out.
2024-01-19 15:57:05.395893 [002] [E] [module]:0508 Publisher fred-r2Vpm04xGY received connection error: Redis Error - kind: IO, details: Connection closed.
2024-01-19 15:58:00.392975 [003] [E] [commands  ]:0615 fred-r2Vpm04xGY: Disconnecting after error processing command: Redis Error - kind: IO, details: Missing connection.
2024-01-19 15:58:00.393267 [003] [E] [module]:0593 Failed to ping redis server with Unknown Error: channel closed

As you can see the above logs r2Vpm04xGY never reconnected, yet the is_connected returned true. The code calls  redis.clients().iter().all(|c| c.is_connected()) before the ping and the print "All publishers reconnected".
After the failure of the ping command, the failed client r2Vpm04xGY stays in the bad state, and still never reconnects.
The module logs are basically prints from the on_error and on_reconnect streams.
Additional context
It does not seem to happen all the times, but enough to make our service stuck for a long time.
I will try version 7 and report back.

I couldn't seem to reproduce with 7 after a few tries, so feel free to close if version 6 is EOL-ed.

Thanks for checking and confirming this @tugtugtug. We have a service that uses 6.3.2 and saw the same symptom, but haven't had a chance to test it with 7.1.2 yet. Appreciate you letting me know that it helped.


Ensure Global Uniqueness of Bucket Name Across Many Different Deployments

Bucket names need to be globally unique, i.e. they have their own namespace outside the organization level.  But our current naming is not long enough to ensure that global uniqueness, across many different deployments.
https://cloud.google.com/storage/docs/naming

Will take the first few characters of a hash of the timestamp and org id to minimize name collision.


Isar inspector is not working!!!

No any response!

Don't forget to set inspector: true when open Isar database!!!


Dynamic columns?

Vue.js version: 1.0.24
consumed using: webpack

I am trying to build a table with a few columns predefined and then pushing a few more columns after AJAX, but it doesn't seem to work.
Anything I should be keeping in mind or is it a bug?

It's not a bug, simply unsupported.
The columns prop is not used directly, because the total columns include custom columns as well.
It doesn't seem like a common use-case, but if others will ask for this feature I may implement it.

Hey @matfish2, is there documentation on how to use reactive columns?
Thanks a lot in advance.


Run NSwag in xproj with MSBuild

Hi
I have tried configuring a MSBuild Target in my .xproj file like below to generate CS classes fom JSON schema file using NSwag as per
https://github.com/NSwag/NSwag/wiki/MSBuild
I have followed the below steps

Added NSwag.MSBuild package to the project references via NuGet Package manager.
Added the following in my .xproj file

<Target Name="BeforeBuild">
    <Exec Command="$(NSwagExe) jsonschema2csclient /Name:OrganizationList /Namespace:Organization /input:organization_jsonschema.json /output:MyEntities.cs" />
  </Target>

When I tried to build it is throwing the following error
error MSB3073: The command " jsonschema2csclient /Name:OrganizationList /Namespace:Organization /input:organization_jsonschema.json /output:MyEntities.cs" exited with code 9009.
Tried printing $(NSwagExe) and the value is empty. So I think the build is not able to find the nswag.exe from the local NuGet packages to execute the command.
Can anyone please help me how to fix the above issue?
Thanks,
Shankar

I ran into a similar problem with the PreBuildEvent.  The NSwag package adds the settings for the $(NSwagExe) at the end of the project file so that they are not know when PreBuildEvent is executed.
To fix edit the project file and make sure your command comes after all of the nswag settings.  Mine is at the end.

I only tested it with csproj files...

Hi fcsobel,
Thanks for your reply.
Can you please send those code lines completely as I cannot configure with that image sample.
Also when I used the below import statement in my xproj file the build process is trying to find the 'NSwag.MSBuild.targets' project inside my project directory and not in  the .nuget folder inside my user home directory.

Maybe you have to wait until the .NET Core with csproj tooling is available.

Hey shankartamma,
I thought your .xproj might have the same sequence problem that we run into when adding NSwagExe to a .csproj file.  Whenever we add the nuget package we need to manually adjust the ordering or the PreBuildEvent section.
I don't think the lines from my project file will be of any help but here they are:
<Import Project="..\..\packages\NSwag.MSBuild.8.6.0\build\NSwag.MSBuild.targets" Condition="Exists('..\..\packages\NSwag.MSBuild.8.6.0\build\NSwag.MSBuild.targets')" />
  <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('..\..\packages\NSwag.MSBuild.8.6.0\build\NSwag.MSBuild.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\NSwag.MSBuild.8.6.0\build\NSwag.MSBuild.targets'))" />
  </Target>

Is this a duplicate of this? https://github.com/NSwag/NSwag/issues/558
Can you test with CI NuGet feed? https://www.myget.org/gallery/nswag-ci

xproj is deprecated and no longer supported...


HTML page with all the reviewed preprint content for PDF generation

We need an HTML page with all the reviewed preprint content so that Coko can generate PDFs on the fly using Paged.js
The page should have the following:

preprint content
peer review material (Review summary, Reviews and Author response)
curation labels
badges (not yet)

Sub tasks

[x] #303
[x] #326
[x] #113
[ ] #

@BlueReZZ I vaguely remember Coko saying that this page shouldn't use some javascript. Is that correct?
The second question is, do we need this to be done this sprint?

This only needs to be the HTML as the styles etc. will be rendered by the paged.js template. You can exclude the javascript too but I think it gets ignored anyway.
Julien will begin work on our project on Tues 23rd August and his initial plan was to generate what we had using the templates he already has. Having this page available for him soon would help his investigations but we can also use the HTML we render on the two pages for his initial investigations. So this sprint would be most helpful but it can wait until next sprint if that's more convenient.

Ordering of elements pretty much as on the main page, but with the peer reviews and author comments at the bottom after the article body.

@scottaubrey @will-byrne to check what is broken with regards to feedback that images are not displaying

Unsure if Coko need new HTML - will check with Ryan as we know they are working from an old HTML from the old EPP.

Ryan has confirmed this is the list they have: https://epp-node-prototype.elifesciences.org/ Ryan believes this is the latest from BioRxiv. @scottaubrey  can you confirm please?

I'm not sure how well the comment above had aged, but that is an obsolete page, that we want to remove: https://github.com/elifesciences/enhanced-preprints-server/issues/432


@conda-forge-admin, please add bot automerge

Issue:

Environment (conda list):

$ conda list

Details about  conda and system ( conda info ):

$ conda info

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/uncommitted-feedstock#12.


Keyboard shortcut for starring a repository

What do you think of a keyboard shortcut to start/unstar the current repository?

When browsing things you could star multiple things and look them up later.
When you visit a repo from a link while doing something else, you might want to quickly star it and close the page.

Having a keyboard shortcut would allow you to keep your two hands at the keyboard.
s is already taken for focusing the search bar.
It could be gs. Thoughts?
What do you think of using it toggle the starred state or should it be just for starring?

I guess it could be useful. I would expect it to toggle.

Make sure you also send this feature request to GitHub<EMAIL_ADDRESS>


Kotlin Project Failed to load to IntelliJ while Testing

Description of the bug:
Hi Team,
We have observed that the Kotlin Project is failing to load into IDE with below console output
Updating VCS...
Running Bazel info...
Command: bazel info --tool_tag=ijwb:IDEA:ultimate --override_repository=intellij_aspect=/usr/local/google/home/satyanandak/.local/share/JetBrains/IntelliJIdea2024.2/ijwb/aspect --override_repository=intellij_aspect_template=/usr/local/google/home/satyanandak/workspace/v2024.10.22/intellij/.ijwb/aspect --curses=no --color=yes --progress_in_terminal_title=no bazel-bin bazel-genfiles bazel-testlogs execution_root package_path output_path output_base release starlark-semantics java-home --
Which category does this issue belong to?
Intellij
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Open Project
Remove “examples” from  v20YY.MM.DD/intellij/.bazelignore file
Open the IDE after installing the Bazel plugin you built
Select “Import Bazel Project”
Select v20YY.MM.DD/intellij as your workspace then click Next
Select “Import Project View File” and point it to v20YY.MM.DD/intellij/examples/kotlin/simple_project/simple_project.bazelproject then click Next.
Which Intellij IDE are you using? Please provide the specific version.
IntelliJ IDEA 2024.1.7 & 2024.2.4
What programming languages and tools are you using? Please provide specific versions.
Kotlin
What Bazel plugin version are you using?
2<IP_ADDRESS>.1-api-version-241 & 2<IP_ADDRESS>.1-api-version-242
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?

I think you need to use bazelisk instead, can you download it from here and add its path in the IDE by navigating to File -> Settings -> Other Settings -> Bazel Settings and put the path in Bazel binary location then try importing again.

@mai93, Thank You ! followed the steps and worked for me.


Please describe example how Pool is initialised with a concrete serverless backend

There is no example on how to use the pool API with a concrete backend.

How do I specify for pool a serverless backend?
`# from multiprocessing import Pool
from lithops.multiprocessing import Pool
import random
def is_inside(n):
count = 0
for i in range(n):
x = random.random()
y = random.random()
if xx + yy < 1:
count += 1
return count
if name == 'main':
np, n = 96,<PHONE_NUMBER>0
part_count = [int(n/np)] * np
pool = Pool(processes=np, initargs={'runtime_memory': 4096})
count = pool.map(is_inside, part_count)
pi = sum(count)/n*4
print("Esitmated Pi: {}".format(pi))`

OK I tried this now which seems to work:
pool = Pool(processes=np, initargs={'runtime_memory': 1024, 'mode':'serverless','backend':'code_engine','runtime':'ibmfunctions/lithops-ce-3.8.5-2.2.9:1.0.0'})

@JosepSampe does it documented somewhere else?  or the usage of Pool is  a missing part that need to be added?

@gilv Docs of multiprocessing are in progress. We will submit them soon.
In any case, apart of using initargs, a concrete backend can be also set in config as usual, in serverless section: https://github.com/lithops-cloud/lithops/blob/master/config/compute/code_engine.md#edit-your-lithops-config-and-add-the-following-keys-1

Docs added in #473


examples: Fix subject selector in ingress policy

This policy example selected all Endpoints rather than just the
Ingress Endpoint. Since the policy is intended to allow traffic to the
Ingress and not other managed Endpoints, restrict the selector.
Fixes: b68cf99c3bb5 ("ingress: Update docs with network policy example")
Fixes: #31060

/test


Character info request fail

Bot seems to be unable to request character info from character.ai upon ".set character [char id]" command

Servers were down for some time. Download last update and try again.

nvm problem fixed. ran it in a linux vm


Optimize products filtering

I want to merge this change because it optimizes products filtering in various of places in product filters.

It no longer makes an exist within exist to just join a channel while explicitly assuming there exists one.
Handles case where there is no channel so further filtering by ProductChannelListing is redundant and can be skipped entirely.

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations

Docs

[ ] Link to documentation:

Pull Request Checklist

[ ] Privileged queries and mutations are either absent or guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migrations are either absent or optimized for zero downtime
[ ] The changes are covered by test cases
[ ] All new fields/inputs/mutations have proper labels added (ADDED_IN_X, PREVIEW_FEATURE, etc.)
[ ] All migrations have proper dependencies
[ ] All indexes are added concurrently in migrations
[ ] All RunSql and RunPython migrations have revert option defined

Will be released differently, closing


add rollup input to geth ecpairing precompile benchmark inputs

Instead of creating a new geth branch, use geth_ecpairing_precompile_rollup_input.patch to add a new input to the precompile benchmark set. Alternatively, we could add the rollup input using solidity/EVM code to call the ecpairing precompile.

Why not just merge it in?


Getting all media from signed in user

Checklist

[x] I've the latest update of Swiftinstagram.
[x] I've searched for existing GitHub issues.
[x] I've read the wiki pages.
[x] I've read the contibution guidelines.

How can I get the all media from user? I can get recent 20 media but, I want to get all of them and then will choose lowest liked medias.
Thanks in advance!

Hi @onurgenes, you can get more media by specifying how much you want with the count parameter, something like this:
api.recentMedia(fromUser: <YOUR USER>,
                count: <HOW MUCH MEDIA YOU WANT>,
                success: ...,
                failure: ...)

Even so, I think the maximum media returned per request is 33, if you specify more than that the Instagram API replies with pagination results, which is something that I'm still working on.

Hello there @AnderGoig,
I think I need pagination support. I need to take all photos and choose the photos which is shared in 2017. So I am eagerly waiting you to support that feature!
Thanks!

I've been working on this and I have created a new branch called pagination to test this feature.
The problem is that this feature is limited to non-sandbox Instagram clients, so I can't test it with mine :confused:
Is your Instagram client out of sandbox mode? Because that will be perfect to test it.

I will send my Client for a submission. Let's if it's going to work.

Thanks @onurgenes, I hope they accept it!

But first, I need to finish the app. If they accepts, I can share the client info with you. Thanks for hard work!

You're right. I'm removing this branch for the moment.


Cat Photo App Step 44 allows multiple type attributes

Describe the Issue
Step 44 will pass if the new radio input is given multiple type attributes.
Affected Page
https://www.freecodecamp.org/learn/2022/responsive-web-design/learn-html-by-building-a-cat-photo-app/step-44
Your code
This will pass:
<input type="radio" type="text"> Indoor

Expected behavior
Step should fail if there is more than one type attribute, even if they all have the value radio.
Screenshots
No response
System

Device: Desktop
OS: Linux (Fedora 36)
Browser: Firefox
Version: 104.0.2

Additional context
No response

I was playing around with this issue, and was able to replicate it locally. Looks like the .getAttribute() JS function only returns the first attribute in an HTML element, so as long as the first "type" attribute is radio it passes the tests.
I was able to fix this with a regex check that looks explicitly for a type="radio" and checks for any additional "type" text in the input. I feel like this could be bypassed if someone had a type attribute at the beginning of the element, some additional attributes, and then a second type attribute.
Maybe just simplify the whole thing by checking for the number of attributes on the input, and if it's more than one, throw an error? It wouldn't be specific to more than one type attribute, but could be like "Your new input element should only have one attribute, the type attribute" or something like that.

At the end of the day, the output is correct - parsed HTML is valid.

According to the <IP_ADDRESS> Attributes:
"There must never be two or more attributes on the same start tag whose names are an ASCII case-insensitive match for each other."

We kind of go back to #46463
In this specific case we can patch it up with a test that check there is only one attribute of that type.

Is this issue resolved ?

@nayabatir1 no, but there is a PR open that targets this issue

@nayabatir1 no, but there is a PR open that targets this issue

From my past experience it's better to not create pr if an issue already has  a pr.
Do let me know if that pr is not up to the mark and new pr are welcome.

Hey I did some research and found that

even if add duplicate attribute is added, DOM node only consider the first one and just ignore the rest. reference
'getAttribute()` will return only first attribute

I'm not sure how to validate this.

only consider the first one and just ignore the rest.

This is why I disagree with trying to test for this - there are an infinite number of incorrect ways Campers can get the correct output.

I'm not sure how to validate this.

We would need to use RegEx.

One cannot test by accessing DOM node, inorder o test it we need to check actual text that user has entered in the input box.

This is why I disagree with trying to test for this

I completely understand this sentiment. If you want to close this issue and forget about it, it won't hurt my feelings :smiling_face_with_tear: But the specs definitely do not allow it and the W3 validator will throw an error. But I suppose you could have this problem with every step. I think @ieahleen was onto something and this is really more an issue of whether we should validate the HTML. So ya, I vote to drop this issue.

As such, I am closing this in favour of the previously linked PR tracking possible HTML validation. no hurt feelings


Add support for Localize full replace

When uploading a template file to Localize.biz, there is the option to remove any non existent key. Add this setting to the available options on the JSON config file and do destructive updates.
Note: How could we make this safer? Maybe have a backup feature to download the contents before?

Regarding the safety aspect, we can add a backup option to the config (default is false) where it downloads the contents before doing a destructive update and places them in a backup folder like .i18n-midoru-backup in the root where the json/lock is. Everytime we do a destructive update, we overwrite the backups in that folder, meaning we would always keep the previous version of the content.
As an extension of this idea, we could also have the backup option be a number which means the amount of backups we keep per project (config entry). This way, we would backup the contents until we reach the given number and after that remove the oldest one for the new content. This would give the user more safety since it might not be apparent when the damage was done and they might have already done various destructive updates, losing the translations.

It seems to complex for what is needed. Given that Localize offers the other option, we don't need anything. Perhaps a double check question, although this would need to be cancelled when using the CLI version.