Add target: "universal"

Do you want to request a feature or report a bug?
feature

What is the current behavior?
targets are pretty restrictive and a web bundle can't be used in node or webworker.
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
The universal target includes runtime code that runs in web, webworker and node.js. The code can be a bit bigger to support all of them.
If this is a feature request, what is motivation or use case for changing the behavior?

Create UMD bundles that work in all enviroments
Create bundles with chunks shared between web and webworker.

@sokra Can I give it a try to implement this?

Sure

@montogeek any luck on this?

I did an exploration about how to add it, you can see it here https://github.com/montogeek/webpack/tree/feat/universal-target
But couldn't did further, need to know more about webpack internals

@montogeek have you made any progress on this? The branch that you mentioned doesn't seem to be available anymore.

@emilio-martinez I restored the branch, didn't make more progress than the initial commit

@sokra would you mind advising @montogeek to move forward?

What the universal target solve my problem? https://stackoverflow.com/questions/49354186/webpack-common-chunks-for-code-shared-between-webworker-and-web-code
I think that web+webworker code is so common that this target is a must have. Else you cannot create common chunks between the two.

Would it be a worthwile idea to discuss if the current target solution could be superseded by a more general approach which maybe can be shared across multiple tools? For example I currently partially configure my target environment in multiple tools at the same time like Webpack, Babel and TypeScript. I created a comment explaining this in the browserslist repo, which is AFAIK the only format/config which currently tries do something like that (besides not "yet" fully supporting non-browser environments) which is also used by many popular tools in the community (like Babel or Autoprefixer). I just would like to see, if there is some interest in this from the Webpack community as well. This is the comment: https://github.com/ai/browserslist/issues/75#issuecomment-374872296
Thank you 👋

@sokra - could we just change the default output.globalObject to "self"?  It should be consistent across all of the necessary contexts for the web output target.

If I remember correctly, just changing the output.globalObject isn't sufficient because of the environment specific runtimes that exist:

Web (https://github.com/webpack/webpack/blob/fde018300aa52262c384e937c408d5dd97d62951/lib/web/JsonpMainTemplatePlugin.js#L96-L139)
Web Worker (https://github.com/webpack/webpack/blob/fde018300aa52262c384e937c408d5dd97d62951/lib/webworker/WebWorkerMainTemplatePlugin.js#L44-L56)

That said, I'd love to have this 👍

Not only that but also approaches to handle the JsonpTemplates which handle lazy loading and splitChunks (aka initial chunk groups)  in their respective envs

Why it can't remain as it was implemented in Webpack 3?
(function webpackUniversalModuleDefinition(root, factory) {
	if(typeof exports === 'object' && typeof module === 'object')
		module.exports = factory();
	else if(typeof define === 'function' && define.amd)
		define("libName", [], factory);
	else if(typeof exports === 'object')
		exports["libName"] = factory();
	else
		root["libName"] = factory();
})(typeof self !== 'undefined' ? self : this, function() {
...

@felixmosh Top-level this doesn't work in Modules:
https://jsfiddle.net/4ogrk3b0/3/show/

Ha, thank you for the explanation.

This looks like a bug. Webpack 3.x built HMR with hot reload. as other issues point to, so whatever is the choice, it should be noted that this appears to be a feature request to fix a bug introduced in 4.x

@sokra , @montogeek , is there a roadmap for this being resolved? Or documentation somewhere for working around it?
Could use some direction. Was just trying to follow the instructions from https://webpack.js.org/guides/author-libraries/ when I ran into this problem.

Would it be a worthwile idea to discuss if the current target solution could be superseded by a more general approach which maybe can be shared across multiple tools?

Just as a small ping, browserslist would now technically support setting Node as well. I still would love to see one way across multiple tools to specify my target environments.

I just want to mention that this would be useful for me. Having trouble getting web workers to work with webpack....:/

globalObject: `typeof self !== 'undefined' ? self : this`

@zhihuilai thanks, that works!

This option seems to work
globalObject: '(self || this)'

The option suggested by @igodorogea doesn't seem to work with node. Or at least through vs code node debugger.
globalObject: (typeof self !== 'undefined' ? self : this) seems to be working for every case thus far.

Any luck 14 months on?

It is open source, PR welcome, there a lot of other problems/features with more priority, thanks

I was submitting a WIP PR(#8579) for this in Jan and ask for some discussion to moving on but actually got less response. I'd like to continue if it could get more feedback.

@mc-zone :+1: Will reviewed in near future

Created a small plugin which works in the meantime:
class FixWebWorkerHMRPlugin {
	apply(compiler) {
		compiler.options.output.globalObject = '(typeof self !== "undefined" ? self : this)';
	}
}

Any chance target: "universal" would fix the existing de-optimization when targeting amd output such as https://github.com/webpack/webpack/issues/5489? In that issue all of the chunks external dependencies are hoisted to the main bundle AMD dependencies, which means the main bundle will load in dependencies via the AMD loader that aren't yet needed.

The work-around that I'm now using: https://www.npmjs.com/package/webpack-global-object-x
Based on work by Mathias Bynens: https://mathiasbynens.be/notes/globalthis

Another solution would be using the direct source of the globalthis implementation:
module.exports = {
    ...

    output: {
        ...
        globalObject: `(() => {
            if (typeof self !== 'undefined') {
                return self;
            } else if (typeof window !== 'undefined') {
                return window;
            } else if (typeof global !== 'undefined') {
                return global;
            } else {
                return Function('return this')();
            }
        })()`
    },

    ...
};

Any update if this will be fixed (or target: 'universal' available as option) in v5.x.x?

Hi dude, i tried these last solution output: {         ...         globalObject:(() => {
if (typeof self !== 'undefined') {
return self;
} else if (typeof window !== 'undefined') {
return window;
} else if (typeof global !== 'undefined') {
return global;
} else {
return Function('return this')();
}
})()     },
and other solutions. I don't receive window is not defined anymore but my web worker does not work :( My application go straight without throw errors and get the workers :(

Hello @sokra , I want to contribute in this,how should i start it.
I was going through setup the project. I am here to contribute as gsoc contributer


serde feature

To switch two features

num-complex/serde https://github.com/rust-num/num-complex/pull/7
ndarray/serde1

resolved in #116


Can't display single post in hero

I'm trying to have a single post displayed on this half of the hero:

I've figured out how to divide the hero into two halves with flexbox , but I can't seem to be able to get the code for displaying the single, latest post right. Here is what I have:
{{ $articles := slice }}
{{ with first 1 (where site.RegularPages "Type" "post")}}
  {{ $articles = . }}
{{ end }}
{{ return $articles }}

But this just removes the hero entirely and puts Pages (1) in its place.

How do I just display a single post on that half of the hero?

Fixed. I was not using the . correctly. Here is the code that now renders only the latest post:
{{ range first 1 (where site.RegularPages "Type" "post") }}

                    {{ .Title }}

                    {{ .Params.excerpt }}

                    {{ .Date.Format "January 2, 2006" }} • {{ .ReadingTime }} min read

{{ end }}


Discord invite expired

Sorry for the silly issue but the discord invite link in the Readme is expired. Thanks! Great project here.

Oh, will update. Am afk right now. Please use this in the meantime. https://discord.gg/2Gb3jWqqja


[WIP] - Temp. fix for 'Browse Entry Point' treeview

This PR restores a working 'browse entry point auto-magically expanding' treeview, which broke due to recent changes in 'patternfly-bootstrap-treeview'.

This PR changes SUI dependency to the core 'jonmiles/bootstrap-treeview' until the 'patternfly-bootstrap-treeview' fork is fixed.  The 'patternfly-bootstrap-treeview' issues are tracked here.
This allows continued integration with the MiQ Automate RESTFul API while 'patternfly-bootstrap-treeview' is being worked on.  Once fixed, we will switch back to 'patternfly-bootstrap-treeview'.
@serenamarie125 , @bleathem , @skateman, @priley86
JIRA Story: SUI: Fix treeview in Browse Automate Entry Point Dialog

@miq-bot add_label euwe/no

@miq-bot add_label wip

Hmm...looks like 'bootstrap-treeview' requires bower, which isn't part of SUI anymore.  Is this PR a no-go then?  Probably not worth re-introducing Bower for a temp. fix.  Unless we want to fork 'bootstrap-treeview' and make it work sans-bower, but again, probably not worth it.

@dtaylor113  thanks fo da holla! is below the repo for the dependency?
https://github.com/jonmiles/bootstrap-treeview
If not, and the dependency isn't published on npm, we'll have to manually add it to the package.json by the repo name.
If so, lets go with that, install it using yarn, and don't forget: https://github.com/ManageIQ/manageiq-ui-service/blob/master/docs/code_tour.md#adding-dependencies (though this apparently needs formatting) 🌮
adding in bower is 🙅♂, we'll find another way

Hi @AllenBW, thanks for the reply.  Yes, that is the dependency and it is published on npm.  I did update the package.json file.  If all builds and runs great locally, but TravisCI is barfing because in '/node_modules/bootstrap-treeview/package.json' there is an install script:
"scripts": {
    "install": "bower install",

I don't know how to have yarn ignore it.  There is a yarn.config '--ignore-scripts' but I don't think we want that for all SUI dependencies.  Looking for a way to just not do the install script for this one dependency.  -thanks!

@dtaylor113 AH!! I understand now, looking presently 💃

Thanks @AllenBW , but don't spend too much time.  This is just an attempt to continue development while the real fix is being worked on.  It we can't get it to play nicely with SUI, I can just punt this PR and wait for the real fix.  :smile:  -thanks

@dtaylor113 so I thought it might have been our version of yarn, the latest proved that this is not the case.  Given the only one requiring and whining about bower is travis and that it in no way is being added to the build process, I'm ok adding bower to travis script so this can go forward for the time being.
thoughts @chriskacerguis  ❓

Hi @AllenBW , @chriskacerguis , no, I wouldn't pollute SUI just for this temp fix.  I've been working with @bleathem and he got me to a point where I know how to get what I need from pf-bootstrap-treeview.  So, I'm going to close this PR and try to get the PF bootstrap treeview fork working.
Thanks for the help!!!! :+1:


How to calculate the xpos from the pos

Hi,
I am a student and trying to figure out how to calculate the xpos given the pos. From this stackoverflow post
. I infer that the the xpos is the position in the global frame and the pos is the position wrt to the parent.
I am using the xml as the humanoid_cmu from dm_control.
I calculate the xpos as
xpos =  pos_body + pos_parentBody + pos_parentBody_parent +....
which doesn't give correct values
this is a snippet of the xml

just looking at this we can say that the xpos calculated by my method on
lfemur would be = pos[world] + pos[root] + pos[lhipjoint] + pos[lfemur] = [0.102, -0.092,  1.05]
but the xpos which I get from mujoco with data.body(3).xpos is [0.102 -0.05   0.908]
What is the cause of this? I think that the relation of between pos and xpos might have been misunderstood by me so want to clarify how this actually works.
Thank you.

Hi, it's a full frame transformation not just a sum of positions, i.e. there is also a rotation between frames. Have a look at
https://github.com/google-deepmind/mujoco/blob/main/src/engine/engine_support.c#L1812
Hope it helps :)


Re: Chaos, lost trust, grief and restoration

Good post. Still disappointing when someone like Tim says you "positively had to do something" in response to the Twitter cesspool, but I can appreciate that it's a difficult situation for all. Even worse when he is encouraging us to use the cesspool rather than MSE 😖
I think it would be great if SE adopted something like the petition system several governments have, where over X signatories will get an official reasoned response.
Finally, the original reason I came to post a response: the link to the "improved review queue indicator" goes to the Christianity site instead.

(Please use this issue for comments on Chaos, lost trust, grief and restoration.)

I'm not actually sure what Tim meant by "So, use Twitter. Use email. Use meta". It seems more like an expression of frustration than a suggestion to get change requests to us. We really could use a bug/feature tracking system and maybe we'll get one?
A petion system is an interesting idea. I worry it would end up like the White House system which has such gems as "Declare George Soros a terrorist and seize all of his related organizations' assets under RICO and NDAA law". It neither got nor particularly deserves a response and so it makes the whole system look a little ridiculous. But it's certainly something I could see us trying.
Thanks for the wrong link report, by the way. I'm not sure why I had the Christianity link in my clipboard to paste there, but I suspect it had something to do with lifting the HNQ restriction.

@terdon:
Thank you for the kind words and the honest criticism.  It occurs to me that I've now spent more time being an employee than a regular user of the site, so my perspective is drifting away from what it's like for this to be an endeavour of passion rather than a way to feed and house my family. (Though I'm still trying to hang onto that as much as I can.) So it's possible I'm too far in to have perspective, but I'm not so concerned about when the response comes as long as we've really learned something.
The seeds of this particular controversy were planted years ago, in my estimation. Companies, like online communities, are more than the sum of their parts. We've institutionally assumed that our users generally agree with what we are doing, but that's somewhere between coincidence and good fortune. (I alluded to this in the post.) I hope this is finally the wakeup call to change that assumption. Working this out as an organization is not something that can happen in a few days or even weeks, however.
I know you all feel helpless and so do I at times. But I think writing up how you feel would be productive. Folks might disagree about your interpretation of events, but what you experienced is not up for debate. (And if anyone does argue with you on that, let me know and I can pull them aside to explain that it's not cool.) Twitter, our chat rooms and even meta tend to be poor places to discuss this sort of thing. Medium is a much better venue in my experience (as Monica demonstrated).
Obviously, I can't make promises that our company will fix this breakdown in trust. It doesn't look like it from the outside, but everyone I know in the company appreciates the work our users do. Part of the problem is that we don't understand what it's like to be a moderator or to feel responsible for the actual content on the sites. Many of the newer employees have never used the sites except as consumers. (And, as I said above, even those of us who were active no longer experience it the way you do.) So that's why I think it could help.
There's a bonus challenge you might consider: try to think about what it must be like for an employee in this situation. Not me or a CM, but a random developer. Imagine if your loyalty were to the company (because it's full of people you respect and also how you earn a living), how would you respond in this situation? Again, this isn't to put the onus on you, but rather as something potentially productive to try. If nothing else, it might be an interesting Socratic exercise.

Part of the problem is that we don't understand what it's like to be a moderator or to feel responsible for the actual content on the sites.

Kicking thoughts off the top of my head straight into this thread here.
What if we had (for want of a better name) "moderator advocates"? Those would be people, selected by SE from the moderator corps for their calm demeanor and communication skills, who effectively would function as mediators between moderators and SE. I suppose they could function likewise for regular users, but regular users already have moderators to communicate between them and SE; moderators don't because they are that mediative/communicative function at the moment.
This comes to mind because it's seemed to me that SE is having a harder time engaging with communities - including the moderator community. As the moderator corps gets bigger, which it can only continue to do, I wonder if that's actually been counter-productive for SE's ability to just drop by TL and shoot the breeze and occasionally get things done in conjunction with moderators. I wonder if we had that kind of moderatrix-advocatus role, that might serve to alleviate some of that. Give them access to a private chat on chat.MSE where they can talk directly with SE staff, particularly to help in these kinds of situations.
I'm thinking of people like Monica for this kind of role - I'd also have suggested Catija, but that kinda doesn't work any more :) If we could find three or four such people and try it out for a while -- this might be too many levels of abstraction, but I wonder if it's worth a try.

I don’t want this comment to just be me banging the same drum as everyone else, but I have a feeling it is going to be.
We’re getting angry. Not passionate, or thoughtful or rational. The community has gone beyond the point of wanting to help you, and to change the network for the better, through a state of resignation where we accepted that things might not be changing, but it wasn’t too bad to now, where Twitter is listened to and changes are made live in minutes. Come on. Twitter. It’s pretty much tumblr.
The community doesn’t just feel ignored, they are ignored. That is, when you’re not blaming them for the company’s shortcomings.
You’ve blamed us for being unwelcoming after you ignored 100s of meta requests to be more welcoming (1 2 3 4 5 - there’s more. I got bored).
You used to tell us what you wanted to do, and asked for our input.  We’ve now reached the point of you telling us what you’re doing, not explaining why, and ignoring 80% of the issues users raise. Like come on, you’d not thought it through, and you couldn’t even concede custom voting buttons... I really hope you  understand exactly why veteran users are frustrated. We see the sites we built being slowly taken apart, as we are pushed to the periphery, and it’s devastating.
 Each time I see a post from you guys that is so negatively received, way beyond just the normal Meta response, I really hope that is the last one. But it never is. You need to take some of your own advice, you need to think before you do (come on, this is pre-school advice here - why am I having to say this to you guys!?) and slowly regain the trust of the veteran users.
I completely understand that your company needs to make money. But I think you have forgotten the new users will only arrive if there is new content arriving too.  This is a technology site - I’m sure you know just how quickly tech changes,  and without new content you will be consigned to the history of the Internet, with my space, USENET, and all of Google’s long forgotten projects. And that new content? It is produced by us, almost exclusively. You can’t make the trade-off between new users and experienced users like you are at the moment, it simply is not sustainable.
I really hope that the next Meta scandal that occupies my attention for multiple days with not be started by a developer, urgently pushing unnecessary changes in response to a tweet. I’m not expecting you to start communicating perfectly 100% of the time. To be honest, I’m not even expecting you to start communicating well. But I really do want you to improve, and I truly hope that you define my expectations.

Hey @timtjtim
Thanks for the feedback. I've certainly seen a lot of anger. I used the word "betrayed" in the post, but I recognize that's not the only cause for anger among our users. I'm not gonna try to convince you to feel otherwise.
I would like to push back on a few points surrounding the new theme. In retrospect, I wish we'd started with the simplest themes rather than attack the most complex out of the gate. (Joe and several others on the DAG team agree.) If you look at some of the more recently released themes, you'll see we are listening to user feedback and introducing more customized elements. In particular, fonts and badges can now be customized per site.
Does that mean we are doing a good job listening? Obviously not. Part of listening is making sure the other person feels heard and that's clearly not the case.
That we responded to Twitter and have not been responding to many meta suggestions has been frustrating to me too. Jay wrote a semi-official response on Twitter. Unfortunately, the people who initiated this on Twitter don't seem interested in working on a solution.
At any rate, thanks for the response and I hope we can do better too.

Betrayal is a good word here.
It's now been almost three weeks.  We've been super-patient, we've explained why it hurts, we've tried to give the team space to make a coherent response rather than a hasty one...  and 20 days later, we have some supportive tweets (thanks Tim and Jay), an intention (on meta) to have a policy, but no further visible movement on the problem.  Some of the other responses come across to me as circling the wagons.  I think it's fair to say that a decent number of mods and users feel disenfranchised by things SE can fix.  I know you're optimistic, but I'm not, yet.  I want to be, but I still feel more hurt than optimistic.
There are two threads and y'll need to pay attention to both of them:

The damage done by hasty actions from people acting publicly as employees.

The chance of it happening again.

New policies address 2, but there's still an awful lot of hurt from 1 and I don't see that going away.  There comes a point when "we're making policies so it won't happen again" isn't enough by itself.  It's uncomfortable to examine one's past deeds, admit error, apologize and make amends, but we can't just pave over the past, not for serious betrayal like this.  You can't look only to the future here; you need to repair the damage from past actions.  You need to address both 1 and 2.
How? That part I don't know.  There are things that would have helped weeks ago, but that ship has sailed.  You need to attend to the very real human volunteers who have very real feelings of hurt and betrayal caused by SE's actions.  You're going to have to trust us that those feelings are real, even if you can't understand them.

Trying to summarize so I can be sure I understand:
The initial response to Twitter was notably quick and, in the sense that not everyone who had a stake in the decisions was consulted, hasty. We've made some progress in preventing that from happening again, but we have yet to address the past hurt in an official capacity. Worse, there's a stark contrast between the initial response and the response y'all are still waiting for.
If I'm understanding you correctly, I have a couple of questions:

By "hasty actions" are you mostly thinking of what we did on the site (removing IPS from the HNQ list) or what we did on Twitter?

If it's just the stuff on Twitter, I'm confused about what the actual harm has been. An employee spoke out of turn without a full understanding of the situation. Those of us on the community team have responded in various places basically pointing out the impression he gave was wrong. Yes what he said was hurtful, but he was under the mistaken impression someone had done far worse things than actually occurred. (I put a healthy dose of blame on Twitter as a medium and another portion of blame on what I can only call deception on the part of the Twitter user who launched this whole catastrophe. Perhaps this is uncharitable, but I wonder if we've all been trolled.) I can't get my head around the long-term hurt I see except if it's tied to the bigger picture hurt on the network itself.

Ok, so I think I have answers to my questions. If I'm wrong and the pain is really coming from one employee saying something he shouldn't, it's hard to see what you are asking for other than for that employee to fall (or be pushed) on his sword. But I think what's really going on is more Shakespearean:

Two households, both alike in dignity,
In fair Verona, where we lay our scene,
From ancient grudge break to new mutiny,
Where civil blood makes civil hands unclean.

We share this city and depend on each other to some extent. But over the years, our paths have separated to the point where the company and the dedicated volunteers (especially moderators) look at each other with suspicion. In these days of individualism, we don't think of ourselves as beholden to larger groups, but we surely are. (No need to look further than the current election cycle in the US to see that.)
To the degree I stand astride the line between the factions, I wish I could make the grudge go away. But the truth is we need to solve bigger problems than hurtful interactions on Twitter. They might be symbolic and perhaps even the catalyst for change, but focusing on them can never fix the divide between the two "houses". (That's why I wrote the post these comments are attached to. I suspect I jumped to solutions far too soon and that it feels like I'm glossing over the problems.)
Please don't hear me as dismissing the pain you feel! It's very real and I'd love to make it go away. I just worry that we'll continue to hurt you if we don't work out our deeper problems. Impossible to know for sure now, but I wonder if we'd immediately apologized officially and backed off of the changes to the system if that might have only delayed the hurt you are experiencing now.
Like any relationship, we have patterns of behavior. Those patterns help us feel more comfortable in our roles. As a moderator, I'd expect to have the full trust of the company when it comes to my core job. I'd expect the company to help out when there are issues outside of my ability to solve, but otherwise let me do my job. And indeed that is the role we on the community team have tried to fill. The unsettling, even treacherous-seeming, pattern we are now seeing is the company taking stands beyond what moderators and the communities they represent were asking for.
Finding a new pattern will be the key to solving the divide. I'm afraid the old ways are unlikely to come back.

Monica says everything I want to say far better than I can, but I do want to remark on this:

If I'm wrong and the pain is really coming from one employee saying something he shouldn't, it's hard to see what you are asking for other than for that employee to fall (or be pushed) on his sword.

I don't think that employee's tweet is all of the problem, but it's certainly some of it. I doubt it'll make much difference now, but I would have liked it to be retracted at the time. Here's the thing, though - that's not asking for anyone to be stuck with swords or poked with sharp sticks.
This has been said a bunch of times in TL as well. Asking an employee to correct a statement they made in error as an employee is not sharp-stick-poking. It's "hey, you made a mistake, you know, we know, it's not a problem but please make sure it's known that it was a mistake".  It's not even a "don't do that again", because you can assume that people are smart enough to learn from their mistakes.
Controlling what your employees do with their personal Twitter accounts is a problem; I get that. But if your employees use their Twitter accounts to make statements as an employee, representing the company, then asking them to make sure they're accurate is entirely reasonable, personal account or no. What would the problem with this have been?


Convert to video to gif

please check and update me of any changes are required from my side 😄

@ssm0801 kindly check my pr


Bug: Duplicate code generated when using collection2 with react

Code generator generates it twice.

Application here:
meteor-kitchen https://www.meteorkitchen.com/api/getapp/json/yAJ5chM2TA5wDBat2 listswith

@mukulhase I know this is old issue, but it's solved now. Closing it.


Refine the existing BOSH release implementation

Description:
For implementing BOSH releases for WSO2 API Manager product deployment patterns, the existing implementation is expected to be used as the building blocks. The current implementation building blocks require refinements.
Suggested Labels:
Type/Improvement
Suggested Assignees:
chirangaalwis
Affected Product Version:
<IP_ADDRESS>
Related Issues:
https://github.com/wso2/pivotal-cf-apim/issues/10

Thanks Chiranga! May be we can refer the commits or pull requests of those changes in this issue.


coverage not properly reported

The coverage of the repo is much larger than the one displayed in the codecov badge in the readme.
The problem is with GNNlib being underreported, since most of its lines are not tested directly but only indirectly when testing GNN.jl layers.

Maybe one can play with the --code-coverage option, see https://discourse.julialang.org/t/workflow-for-faster-testing-of-julia-packages/113836/19


Excessive stack depth comparing types in useFetch

Environment

Operating System: Linux
Node Version:     v16.19.0
Nuxt Version:     3.1.1
Nitro Version:    2.1.0
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      -
Runtime Modules:  -
Build Modules:    -

Reproduction
https://github.com/mahdiboomeri/nuxt-excessive-stack-depth
Describe the bug
When using useFetch with explicit method in combination of trpc client in a plugin, the following type error occurs on useFetch.
Excessive stack depth comparing types. ts(2321)

My best guess is that this is a regression from https://github.com/unjs/nitro/pull/686 and not directly related to trpc.
Additional context
No response
Logs
pages/authentication.vue:6:7 - error TS2321: Excessive stack depth comparing types 'Exclude<ReqT extends "/api/test" ? { key: "/api/test"; exact: true; score: []; catchAll: false; } : { key: "/api/test"; exact: false; score: `${ReqT}/` extends `${infer RouteSeg}/${infer RouteRest}` ? `${RouteSeg}?` extends `${infer RouteSegWithoutQuery}?${string}` ? RouteSegWithoutQuery extends "" ? `${RouteRest}/`...' and '{ score: MaxTuple<((ReqT extends "/api/test" ? { key: "/api/test"; exact: true; score: []; catchAll: false; } : { key: "/api/test"; exact: false; score: `${ReqT}/` extends `${infer RouteSeg}/${infer RouteRest}` ? `${RouteSeg}?` extends `${infer RouteSegWithoutQuery}?${string}` ? RouteSegWithoutQuery extends "" ? `${...'.

6 await useFetch("/api/test", {
        ~~~~~~~~~~~~~~~~~~~~~~~
7   method: "POST",
  ~~~~~~~~~~~~~~~~~
8 });

I have a similar problem, and I'm not using trpc. (v3.1.1)
import { type FetchOptions } from 'ofetch';

export const useFetchOnboarding = (path: string, options?: FetchOptions) => {
  const config = useRuntimeConfig();

  return $fetch(`${config.public.apiUrl}/${path}`, {
    method: 'POST',
    /*  headers: {
      Authorization: `Bearer ${config.public.authToken}`
    }, */
    ...options
  });
};

LOG
(property) NitroFetchOptions<`${string}/${string}`>.method?: "POST" | "GET" | "HEAD" | "PATCH" | "PUT" | "DELETE" | "CONNECT" | "OPTIONS" | "TRACE" | "post" | "get" | "head" | "patch" | "put" | "delete" | "connect" | "options" | "trace" | undefined
A string to set request's method.

Type 'string' is not assignable to type '"POST" | "GET" | "HEAD" | "PATCH" | "PUT" | "DELETE" | "CONNECT" | "OPTIONS" | "TRACE" | "post" | "get" | "head" | "patch" | "put" | "delete" | "connect" | "options" | "trace" | undefined'.ts(2322)

I am having the same issue after upgrading to nuxt 3.1.1

The issue seems to be fixed in the edge channel

It still doesn't work for me on 3.2.0

Same for me on 3.2.0

I can't replicate on the edge channel or on v3.3.2.
If you are still experiencing this, please do provide a reproduction and I'll happily reopen.

For anyone landing here having the issue with $fetch instead of useFetch: check out https://github.com/unjs/nitro/issues/470

Same issue in a Nuxt Bridge project, i want to wrap my $fetch like this:
const useApiFetcher: typeof $fetch = (url, options) => $fetch(url, {
  baseUrl: useRuntimeConfig().public.backendBrowserBaseUrl,
  ...options,
})

It's actual for me on Nuxt 3.5.2
error TS2321: Excessive stack depth comparing types 'Exclude<{ key: "/robots.txt"; exact: false; score: ${?}/ extends ${infer RouteSeg}/${infer RouteRest} ? ${RouteSeg}? extends ${infer RouteSegWithoutQuery}?${string} ? RouteSegWithoutQuery extends "" ? ${RouteRest}/ extends ${infer RouteSeg}/${infer RouteRest} ? ${RouteSeg}? extends ${infer RouteSegWit...' and '{ score: MaxTuple<((? extends "/__nuxt_error" ? { key: "/__nuxt_error"; exact: true; score: []; catchAll: false; } : { key: "/__nuxt_error"; exact: false; score: ${?}/extends${infer RouteSeg}/${infer RouteRest}?${RouteSeg}?extends${infer RouteSegWithoutQuery}?${string}` ? RouteSegWithoutQuery extends ""...'.
6   return useFetch(request, {
~~~~~~~~~~~~~~~~~~~
7     baseURL: customizationStore.baseUrl,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
50     },
~~~~~~
51   });


Stalemate

There are many situations in chess where the outcome is stalemate, there should be a way for both players to agree that this is the case and end the game, rather than just leaving the board until it can be reset/removed

I guess we could add a "forfeit" button that checks the number of pieces remaining per player and declare a winner according to that number.

I'll close this, too specifical.


Add visual mode word counting

Hello there,
I was surprised that the word counting wouldn't count the number of visual mode selected words.
I've made some straightforward changes to make it possible:
On wordcount.vim
function! s:update()
  if match(&ft, s:filetypes) > -1
    let l:mode = mode()
    if l:mode ==# 'v' || l:mode ==# 'V' || l:mode ==# 's' || l:mode ==# 'S'
      let b:airline_wordcount = airline#extensions#wordcount#formatters#{s:formatter}#format()
      let b:airline_change_tick = b:changedtick
    else
      if get(b:, 'airline_wordcount_cache', '') is# '' ||
            \ b:airline_wordcount_cache isnot# get(b:, 'airline_wordcount', '') ||
            \ get(b:, 'airline_change_tick', 0) != b:changedtick
        " cache data
        let b:airline_wordcount = airline#extensions#wordcount#formatters#{s:formatter}#format()
        let b:airline_wordcount_cache = b:airline_wordcount
        let b:airline_change_tick = b:changedtick
      endif
    endif
  endif
endfunction

And on the default formater (wordcount/formatters/default.vim):
function! s:wordcount()
  if exists("*wordcount")
    let l:mode = mode()
    if l:mode ==# 'v' || l:mode ==# 'V' || l:mode ==# 's' || l:mode ==# 'S'
      let l:visual_words = wordcount()['visual_words']
      if l:visual_words != ''
        return l:visual_words
      else
        return 0
      endif
    else
      return wordcount()['words']
    endif
  elseif mode() =~? 's'
    return
  else
    let old_status = v:statusmsg
    let position = getpos(".")
    exe "silent normal! g\<c-g>"
    let stat = v:statusmsg
    call setpos('.', position)
    let v:statusmsg = old_status

    let parts = split(stat)
    if len(parts) > 11
      return str2nr(parts[11])
    else
      return
    endif
  endif
endfunction

Maybe you may want to add this as a new formatter, but I think this may be the wanted general behavior.
Of course, my vim coding sucks, so you may change it to whatever works better. And I also didn't change the case when wordcount function is unavailable.
Best.

can you submit as PR please?


Adding accreditation & validation to the TCE data type

Adding accreditation & validation, as the calculations done at the TCE level should also be verified, even if they are based on data already verified at the TOC level

Thank you, @GabrielaRubioDomingo!
I grant the motivation, but my question here is whether we should not take one step back and think about whether we want these to be mere booleans (both here and in TOC). Without any further requirements, it's hard for me to see the value of these properties, that can simply be set to true without providing any means of verification.

I think we left the assurance topic as open for the moment. - I thought of adding accreditation and validation at the TCE level, just to be consistent with the TOC category, that includes both variables (i.e if we have it in one, we should have it in the other as well ?)
Of course later on we have to revise all variables relative to assurance & make this more robust.

Closing PR due to inactivity.


docs: update release procedure

Description
Let's discuss release procedure.
Do we want to:

keep as is: both API breaking as well as consensus breaking changes requires major version bump.

Pro: more major release (v3, v4, v5...),
Cons: we need to update proto, scripts, go.mod and all import path whenever we bump

adopt IBC release strategy: https://github.com/cosmos/ibc-go/blob/main/RELEASES.md as well as many core blockchains (go-ethereum, avalanche...)

Pro / Cons: inverse of the "keep as is"

Personally I'm leaning towards IBC strategy, because we more target API.

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] added appropriate labels to the PR
[ ] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

@robert-zaremba, I prefer the IBC method as it is really well thought out.


[NOC-356]  Read industries metadata from SSOT

@rjkuyvenhoven I did some further refactoring - please test on your local machine when you get the chance.
One last thing I'd like to discuss with you is handling LMM industries which as you know are not 1:1 mapping to industry profiles. Right now, the mapping is done in 2 places:

ssotIndustryLMMKey() when displaying LMM data on the Industry Profile page.
LabourMarketEmploymentIndustriesTable::getIndustryHighlights() when displaying the LMM page itself - the only needed data here are the labels.

The first one can be handled more elegantly by simply renaming the LMM industry columns in the SSOT monthly_labour_market_updates endpoint to match the industries keys.
The second one is more problematic, because an LMM industry such as wholesale_and_retail_trade does not have an industry profile equivalent. I am reluctant to add an entry for it in the industries table, but it would still be great to have a way to read these labels from SSOT.  I am thinking to read these labels from the SSOT schema of the monthly_labour_market_updates endpoint.
What do you think?

I've updated SSOT with the changes outlined above - to test, please refresh your SSOT with the dump in this branch.


Suppressing "The import path cannot end with a '.ts' extension" error?

From @hooper-hc on September 30, 2018 8:45
when i use
import { PI } from './module.1.ts'
import an  module .
vscode linter notice  me an error
'The import path cannot end with a ".ts" extension. Consider changing to import “./module.1”。'
hao can i hidden the notice ?
Copied from original issue: Microsoft/vscode#59690

Suppose you have two files:
a.ts: import * as b from "./b.ts";
b.ts: export const b: number = 0;
When we compile a.ts, we don't change import specifiers. So the output a.js will contain the same  import specifier "./b.ts", although possibly translated to require("./b.ts").
Then when you try to run a.js it will fail, because there will be no b.ts to import from, only b.js. (Or without --outDir where b.js is next to b.ts, it will resolve the import to b.ts, then fail parsing at : number.)

no，I use deno exec the file 。 without  compile。

@hooper-hc
I think we can set tsconfig like:
{
  "compilerOptions": {
    "module": "amd",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "http://*": ["../../../.deno/deps/http/*"],
      "https://*": ["../../../.deno/deps/https/*"],
      "*.ts": ["*"]
    }
  }
}

I'm using deno as well. I found that commenting // @ts-ignore each line of an import works.
// @ts-ignore
import coerceToArray from './journey.coerce-to-array.ts'
// @ts-ignore
import fnFree from './journey.fn-free.ts'
// @ts-ignore
import fnReduce from './journey.fn-reduce.ts'

Is there anyway to shut this requirement off globally in ts-config?
I also tried @zhmushan's solution and It didn't fix the issue :(

@reggi remove ./
I hope that in the future, we can use a configuration similar to module:deno to simplify the operation.

Would the TypeScript team be open to adding "module": "deno" to the tsconfig? That way we can support using the .ts extension natively, without needing to resort to something like kitsonk/deno_ls_plugin as a workaround. It could also try and enforce it as well, so if you try and do
import module from 'module';

it would show an error like Cannot have an extensionless import with module:deno (the only imports that are allowed are full URLs, and relative imports starting with ./ or ../). A configuration like that could also support natively searching the $DENO_DIR/deps folder for types, since we currently need to use a path setting to workaround that. On top of this, automatic imports could work properly as well, since they currently always do the extensionless import (meaning you have to manually edit it anyway).

This seems like a duplicate of #11901 which was unfortunately closed and silenced. This is important for Deno as was said before and I hope TypeScript will make this extension check configurable or even better remove it altogether.

In most of the Javascript tooling ecosystem, you can do things like import picture from 'image.png', which obviously isn't Javascript. The assumption is that some tool will know how to transpile the referenced file into Javascript so this works correctly. All types of assets and alternative syntaxes, such as JSX, work this way.
Typescript, on the other hand, expects you to either use a blank extension or the .js extension, which is different from how the rest of the ecosystem works. This causes friction for tools like Deno or rollup.js that expect the original file extension.
If tsc wanted to work more like the rest of the world, it could allow .ts as an extension, and then transform that to .js as part of stripping types at build-time. This is obviously a large change to the way the tsc compiler works. On the other hand, there is a wave of alternative tooling based on Babel and Sucrase beginning to enter the ecosystem, so perhaps there is a long-term benefit in aligning with those tools' way to doing things.

Adding my vote here for support for Deno. The current behavior results in TypeScript resolving all types imported in this way to any, which makes developing software for Deno rather difficult.

Deno's a great idea, but trying to convince the TS team to explicitly allow Deno to resolve modules that way to me is a losing battle. It's much easier for Deno just to handle it because (a) way faster to do so, less effort needed and (b) convincing the TS team to rewire its internals like that is a very uphill battle.

If tsc wanted to work more like the rest of the world

TS is becoming increasingly dominant, it's a good strategy to be as compatible as possible to TS conventions including their tooling. Otherwise projects like Deno will never get traction due to the divergence in something as fundamental as module resolution

@jpike88 I disagree.  I didn't realise this issue existed.  There were a couple other issues semi-related which we were tracking.  This issue doesn't say anything about the intent of the team.  It is still labelled as a question and it could be argued it really is a duplicate of #16577 or #18442.
Ryan's comment though gets to the heart of the problem, that they can possible write out something that satisfies every host, so they restrict it to the most common situation today, which is Node.js's CJS way.
I still think (and I thought I said this in an issue before) is that there might be time for "moduleResolution": "literal" which would do what it says on the tin, and allow TypeScript to assume that whatever runtime host would figure it out/change the module specifiers.

Ok, but:
https://github.com/microsoft/TypeScript/issues/18442
I actually commented in that like two years ago, and it's still after all this time a stage 1 proposal.
https://github.com/microsoft/TypeScript/issues/16577
Also over two years old, still in the 'discussion' stage. Also at the rate it's going, not happening any time soon.
I'm just going off the timescale things have been happening for here, and basing their likelihood of ever happening off that.

Similar issue occurs if you want to directly import an .mjs file
e.g. import { forEach } from<EMAIL_ADDRESS>

This is closed, but it's not fixed.

If anyone here was just looking for a way to be able to run your TypeScript within both the context of Node.js and Deno, know that Webpack + ts-loader will let you keep ".ts" in your imports.

I have this issue whenever I import file from deno? any solution to fix this except adding // @ts-ignore ?

Is this fixed? Importing without extension is not part of the JS anyways, using extensions should not display an error.

I agree with the comments above. It's too bad the problem hasn't been solved yet.
I found an extensions for vscode that should help, but unfortunately it doesn't work properly.
Anyway, I'll leave the links here:

https://github.com/justjavac/vscode-deno
https://github.com/axetroy/vscode-deno

Following @TicTak21:
The links he mentioned are both deprecated now in favor of the official deno plugin:
https://github.com/denoland/vscode_deno

@danbulant I am still seeing the error using the vscode_deno plugin.

I also use Deno but I think the problem here is not about .ts vs no .ts. It's more about the ability to allow tsc to ignore certain error number. For example, something like tsc --ignore TS2691.

The Deno extension for vs code is nice, but it doesn't solve the problem, it just suppresses the error in the editor. I have a library that I want to build for deno and the browser, but I can't because tsc will throw.

I agree 100%. This is the main reason why I do not yet consider Deno as a replacement for the node.js on the server. A good web frameworks for Deno is already available, and only TYPESCRIPT stands in the way of this beautiful dream

For anybody having recent troubles with this, I will say that the deno_ls_plugin despite being archived achieved exactly the result I need. This issue that references the plugin is how I found out about it.
My specific use case is that I am working in an environment with typescript code shared between the client and the server using symlinks. The server is written with deno in mind, and the client is written with regular typescript and phaser3. The bundler I am using, parcel, can handle typescript importing .ts files (at least with parcel-bundler ^1.12.4). That leaves the intellisense to be fixed.
deno_ls_plugin works great for me, because it literally just patches .ts module resolution. Perfect! That means I can import the shared code, and have the shared code be written with deno front and foremost in the mind, and patch the intellisense for the typescript client side of things.
For starters, I ran the yarn add typescript deno_ls_plugin --dev command to install it. After seeing that the intellisense wasn't fixed, I noticed some tiny text at the bottom of deno_ls_plugin's readme, to use the workspace version of typescript.
For anyone else a bit confused about how to do that, here's what I did:
I clicked on a typescript file and clicked on the version in the bottom right corner.

Then, I chose to select the typescript version

and chose the workspace version.

In my specific case, I have also set typescript.tsdk in .vscode/settings.json but I don't know if I needed to.

If anyone else is also trying to share deno code with typescript code, I used symlinks to link to the core code in both the server and client, and had the code inside the symlink reference a deps.ts file outside of it for dependencies (since import_map is kinda meh atm) so that the typescript version can import the npm package and the deno version can import the URLs.

Hopefully this little message might help anybody having similar issues with trying to share deno code between a classic typescript project and a deno project.

I created a suggestion issue here that would solve the problem above. Hopefully we can get some momentum to have that or something similar implemented in the very near future.

This issue needs to be reopened.

The Deno developers are not getting the respect they deserve here. They made an amazing runtime based on TypeScript, but TypeScript developers won't add a flag to allow it to work properly. How can this sorry situtation go on for so long?!
Not being able to use the .ts extension on imports is causing massive pain and problems for Deno users, please help us!

its not actually Deno specific
without possibility to explicitly define extension many JS devs will have problem
for example in our vue project we always specify extensions, or else we'll have problem in situation like
./component.vue
./component.ts

import component from './component';

Why is this closed? Certainly not Deno specific especially with the rise of mjs

This thread is NOT a question, it is a feature request. Please can someone correct the label and re-open it? Manually adding // @ts-ignore to every import is not an acceptable solution.

@zraineri
I have read several threads dealing with this issue. To summarize, core developers just don't want to do this. They say that it can break other things and that the import algorithm is already quite complex and so on.
Consider me crazy, but it seems to me that there was some corporate solidarity here. The company has spent a lot of money on the node (npm). And doesn't want some upstart to rob them of their profits with her own hands.. So I don't think you can expect much friendliness towards deno from vscode or typescript

@zraineri
I have read several threads dealing with this issue. To summarize, core developers just don't want to do this. They say that it can break other things and that the import algorithm is already quite complex and so on.
Consider me crazy, but it seems to me that there was some corporate solidarity here. The company has spent a lot of money on the node (npm). And doesn't want some upstart to rob them of their profits with her own hands.. So I don't think you can expect much friendliness towards deno from vscode or typescript
Luckily, you can use a plugin that already does more than you ask for and will only get better.
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

But the problem is, not only Deno, but also regular
https://github.com/microsoft/TypeScript/issues/27481#issuecomment-664401169

@Hulkmaster
It looks like we need a shiny new typescript. This one is stuck with its legacy problems and can't (or don't want to) implement imports with extensions. The deno team seems to be planning to write their own typescript (in rust, I suppose :)

I am part of the Deno core team.  I agree that the TypeScript compiler shouldn't get involved in rewriting module specifiers.  The internals of Deno suppress this diagnostic message and the vscode plugin for Deno also supresses this message.  This isn't a barrier for Deno.
Trust me that there isn't some hidden Microsoft/Node.js hidden cabal suppressing Deno.  The TypeScript core team, member of the Node.js community and the Deno core team regularly talk to each other and collaborate.

@kitsonk

This isn't a barrier for Deno.

but this is a barrier to the unification of two worlds: Node and Deno. How can I write a typescript that will work on both platforms at the same time if you guys have religious disagreements about importing local files with extensions

How can I write a typescript that will work on both platforms at the same time if you guys have religious disagreements about importing local files with or without extensions.

That really isn't an issue with TypeScript/tsc.  Node.js is headed the way of explicit modules anyways, and how they tackle that will have an impact on the module resolution capabilities of tsc I would suspect.  I believe there are continued conversations there, to be able to better support ESM in Node.js.
Doing as this issue suggests would not really help anyone.  A better solution to the problem was proposed in #33437.

Node.js is headed the way of explicit modules anyways, and how they tackle that will have an impact on the module resolution capabilities of tsc I would suspect

I suspect this will only affect the .js extension. The .ts will still be an error in the typescript and vscode. So it's too early to take off the hat of the global conspiracy against deno, I suspect :)

TypeScript users on Snowpack is also running into this issue. ESM imports in Snowpack are based on the source filename, so import './file.ts' and import Counter from './counter.tsx' are both expected to work. We ask TS users to use the ".js" file extension as a workaround, but we're looking to add new features that might break this for them entirely.
It feels odd that TypeScript wants to both stay out of import resolution (the right call, imo) but also put arbitrary limits in place. I'm +1 this warning as a default to protect new users from footguns in most projects, but projects like Deno and Snowpack should be able to suppress this.

The truth for me is that this is a problem of your setup/bundling process. What I did was to remove the extension and configure webpack to resolve .ts files with:
// in webpack.config.js
resolve: {
  extensions: [".json", ".js", ".ts"],
}

The truth for me is that this is a problem of your setup/bundling process. What I did was to remove the extension and configure webpack to resolve .ts files with:
// in webpack.config.js
resolve: {
  extensions: [".json", ".js", ".ts"],
}

This solves the problem just for webpack. Deno, snowpack, parcel and other tools don't have a way to implement this.

Interesting @VitorLuizC. How's the webpack transformation happening there. Is it just using the tsc?

I would also like to mention eslint rule, which greatly explains why explicit extensions are a great thing
https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/extensions.md

Wait, is the current state of things that it is impossible to write a "cross platform" TypeScript library that works in Deno, Node and on the frontend? This really makes me question the maturity of the language.

Ya know, we could just stop using vsc.

@code913
You probably meant typescript Language Services. After all, they are the ones who report the error. They also still do not know how to load types from package.json exports field (but they can now do a funny thing TeMpLaTe StRiNg TyPes , hurray). Yes, it's definitely time to switch from typescript. Any ideas on what?

Why is this issue closed? It creates lots of problems! Impossible to share code between deno backend and front-end frameworks!

I just use Atom with no typescript plugins. It doesn't crash my ubuntu.

This is nonsense.

monke creates
humanity typescript destroys
ditch typescript return to monke

reopen

reopen this issue?

typescript still wont fix it even if its opened

why not? reason?

I love TypeScript the language, but I agree this won't be fixed. Sadly the JavaScript crowd doesn't seem to care about traditional values like engineering quality or developer experience. Hot New Features or die, seems to be the prevailling sentiment.

JavaScript crowd doesn't seem to care about traditional values like engineering quality or developer experience

Therefore, for now, we tolerate TypeScript and wait for it to be comfortable to write frontend and backend in Rust :)

...when it will be possible to comfortably write the front-end and back-end in Rust

If you want a strongly typed language language, then compile to web assembly :)
I'm no fan of the typescript syntax but i do like a typed language, I only use TS with combination of checkJS + jsDoc

I'm no fan of the typescript syntax

TypeScript is a great language. And node.js is a good platform. But deno is better. And we need both platforms at once, please :)

why not? reason?

They havent for almost 3 years.

This issue is a problem. As currently it's impossible to share files between Deno Backend and React/Svelte Front-End.

So many issues that were created recently got attention and were resolved.
This issue was created on Oct 1, 2018, has 57 comments, a neat proposed solution by @luvies (https://github.com/Microsoft/TypeScript/issues/27481#issuecomment-464456102), hundreds of people interacting and quite a few willing to help, yet it is completely ignored and silenced.
"Open Source"

While I would absolutely love this to be fixed, "open source" means you're free to fork the project and do what you want with it, not that its maintainers are obligated to bow to your whims. Open source is working just fine here.

Forking Typescript is not a solution. The open source community needs to constantly steer towards consistency.
The root of this issue is an inconsistency between Typescript runtime environments.

a "flag" would solve the issue
--i-want-write-extension-explicitly
i also saw a PR here, which added exactly that, but unfortunately core team blocked it ¯_(ツ)_/¯
and so far i see its not a technical or an architecture issue - somebody in TS core team JUST WANTS IT, and thats it, no reason

I believe the fundamental issue why they don't want it is because they're thinking about the case when TypeScript performs compilation, because it is a stated requirement that TypeScript compilation shouldn't affect JavaScript (.js) files, as it would need to when compiling a .js file that contains a .ts import.
I, as I believe many others in this thread, don't want TypeScript to touch JavaScript files, or any files at all, because we're only using TypeScript for checking and not compilation.
Would it be possible to get a flag like above, that only takes effect when noEmit is true?

@jacobmischka well said. I really think this is more of a misunderstanding of the use-case from the maintainers and that this can be implemented in a way that doesn't require any transformation of imports.

I, as I believe many others in this thread, don't want TypeScript to touch JavaScript files, or any files at all, because we're only using TypeScript for checking and not compilation.

I take benefit of typescript with js, JSDocs and followJS. (even use // @ts-check sometimes)
I don't like to have to transpile my code and i don't like the syntax either... i don't like what isn't standardized I only use it for type definitions...

Is there an official statement about this issue? I don't know what is true and what speculation about the reasons.
But I also don't know what exactly is holding this back. The typescript goals state

Align with current and future ECMAScript proposals.

Since imports take the extension  (imo the comment about bundlers in the module-name description is out of place) and with import assertions on the way this seems to be a no-brainer.

This is the stated reasoning that I was referring to in my post: https://github.com/microsoft/TypeScript/issues/16577#issuecomment-754941937

@jacobmischka Thanks for the link.
I think both sides could be pleased if one would consider typescript imports import b from "b.ts" as typescript code instead of javascript code...

Or maybe let's ask  @ry to replace the Typescript with Flow in Deno! There is no need to change the file extensions in Flow ;)

Also, what if I'm importing types and interfaces from a file? Doesn't make sense to use the js extension

For me was enought to remove the file extention .ts from the import and the error went away.

@FedericoCapaldo
This issue is all about keeping the .ts extension and being explicit about what file you want to import instead of having to guess if you meant to import foo.js or foo.ts

MY SOLUTION: For me was enough to remove the file extension .ts from the import and the error went away.

does it work in deno?

Actually this error will be resolved if you use deno extension with VScode

Note more discussion on this is happening at #37582

This is one of those reasons why i stick to vanilla js instead. I have never been a fan of compiling and TS weird syntax ontop of js. It don't really fit into a loosed typed language anyways. Having support for typescript http-imports in Deno is beyond my understanding. You basically have two JIT compilers. TS > JS > V8 and the code will take longer to load

5 reasons why Deno will stop using TypeScript
why deno want remove typescript from your internal code?

And now this with extenssonless import, cjs, esm, mjs, mts and cts extensions becomes a total mess.
i will stick to vanilla js + jsdoc and even d.ts files and refactor all my ts code to js. You don't really need typescript syntax to have typed support.

I have the same problem in a React app with TypeScript. Any solutions?

As others have alluded to, the ESM spec requires an extension, and so in an ESM based world, omitting the extension is definitely going against the grain, and will be so more and more going forward.
In addition, since these ESM based tools are the ones wanting to provide a first class TypeScript development experience, they will naturally be relying on the extension to power said experience.  Thus, with the current choices being

no extension
or use .js

It's really between a rock and a hard place for a lot of us in this thread, and made all the more unfortunate with this issue being closed and dismissed as as question, and seemingly relegated to being seen as only warranting of a SO post.  😞

Is there is no room for conversation on this one from the TS team? 🙏

https://github.com/microsoft/TypeScript/issues/27481#issuecomment-948141952

last post one year ago and first post 2018 and no real solution?
If I don't do a .ts it doesn't find my imports if I do it's all red. Putting a // @ts-ignore over every line destroys the clarity.
How can such a serious annoying bug not have a reasonable solution within 4 years.

@VidarDev check @vasujain's comment

Actually this error will be resolved if you use deno extension with VScode

Doesn't solve every case but you don't need to // @ts-ignore.
The reason there is no solution in 4 years is because this goes against TS team's principles. Not that I agree with them but that's the case.

last post one year ago and first post 2018 and no real solution?
If I don't do a .ts it doesn't find my imports if I do it's all red. Putting a // @ts-ignore over every line destroys the clarity.
How can such a serious annoying bug not have a reasonable solution within 4 years.

Beats me!

I'm having the same issue with moq.ts package. Any solutions?
https://www.npmjs.com/package/moq.ts

@Johannes-B-stock can you open a new bug for that? I think since it’s recognizable as a package name and not a file, the error is a bug even under the current extension handling logic.

Actually, I can’t reproduce that—once the package resolves, the error goes away. I.e., you’d see the .ts extension error if you tried to use it without running npm install first, but once it exists in node_modules, the error disappears. You can see this happen on the Playground: https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgSQHYCsCmBjGAxAGwEMBzAZzgF84AzKCEOAIhAgEcA6GMpgKCA

Removing the .ts when importing solved it for me. i.e import Example from './examplefolder/example'

Thanks for the hint, I found the issue. I exported this as part of a npm package but moq.ts was not in the dependencies, only in devDependencies. If you then use the package in a project that does not include moq.ts, the issue pops up.

just need remove the .ts extension name

- import * as UIComponents from './index.ts'

+ import * as UIComponents from './index'

just needs to remove the .ts extension name
- import * as UIComponents from './index.ts'

+ import * as UIComponents from './index'

Unfortunately that wouldn't work in Deno.

Try to add: "files": ["./node_modules/wmr/types.d.ts"] to tsconfig.json

How come this issue is open for 5 years (!!) with no answer or progress what so ever?

Using this separate VS Code extension worked for me: https://marketplace.visualstudio.com/items?itemName=ameerthehacker.deno-vscode&ssr=false#overview
I'm using Deno and importing .ts files. Not an ideal solution, but at least there's something.

Late to the party, can someone

Suppose you have two files: a.ts: import * as b from "./b.ts"; b.ts: export const b: number = 0;
When we compile a.ts, we don't change import specifiers. So the output a.js will contain the same import specifier "./b.ts", although possibly translated to require("./b.ts"). Then when you try to run a.js it will fail, because there will be no b.ts to import from, only b.js. (Or without --outDir where b.js is next to b.ts, it will resolve the import to b.ts, then fail parsing at : number.)
Instead, you should omit the file extension from your imports, or use the .js extension.

Late to the party, but why won't TypeScript change import specifiers? It seems rather odd that the file is named a.ts but you are importing a.js.

I use custom loaders in Node.js and I cannot stop VSCode from issuing false error messages telling me that imports "cannot end" with various file extensions, which is now strictly false no matter what runtime the user selects using. Why not allow users to set an option to avoid this?

As of about a month ago, you can use:
"allowImportingTsExtensions": true

In your tsconfig.json to enable *.ts imports.

As of about a month ago, you can use:
"allowImportingTsExtensions": true

In your tsconfig.json to enable *.ts imports.

When doing do, I get the following error instead.
tsconfig.json:14:35 - error TS5096: Option 'allowImportingTsExtensions' can only be used when either 'noEmit' or 'emitDeclarationOnly' is set.

14     "allowImportingTsExtensions": true,
                                     ~~~~

Found 1 error in tsconfig.json:14

I just want to be able to use TypeScript and ES6 modules together :c

@Higgs1 what runtime environment is your code executing in?

@Higgs1 what runtime environment is your code executing in?

Currently Deno and modern, standard compliant web browser(s) (Chromiums). Supporting Node too would be nice, but not necessary.

As of about a month ago, you can use:
"allowImportingTsExtensions": true

In your tsconfig.json to enable *.ts imports.

When doing do, I get the following error instead.
tsconfig.json:14:35 - error TS5096: Option 'allowImportingTsExtensions' can only be used when either 'noEmit' or 'emitDeclarationOnly' is set.

14     "allowImportingTsExtensions": true,
                                     ~~~~

Found 1 error in tsconfig.json:14

I just want to be able to use TypeScript and ES6 modules together :c

got top level await, es6 modules and typescript with this config working
default tsc --init with couple tweaks
{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "node",
    "outDir": "./build",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  },
  "include": ["source"]
}

package
{
  "type": "module",
  "scripts": {
    "build": "npx tsc -w",
    "dev": "node --watch build/app.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "mongoose": "^7.0.0"
  },
  "devDependencies": {
    "@types/express": "^4.17.17",
    "typescript": "^4.9.5"
  }
}

import express from 'express'
import mongoose from "mongoose"
import { uri } from './config'
import { router } from './routes'

const app = express(), port = 3000

app.use(router)
await mongoose.connect(uri)
app.listen(port, () => console.log(`http://localhost:${port}`))

no errors just omit the extension on imports

As of about a month ago, you can use:
"allowImportingTsExtensions": true

In your tsconfig.json to enable *.ts imports.

When doing do, I get the following error instead.
tsconfig.json:14:35 - error TS5096: Option 'allowImportingTsExtensions' can only be used when either 'noEmit' or 'emitDeclarationOnly' is set.

14     "allowImportingTsExtensions": true,
                                     ~~~~

Found 1 error in tsconfig.json:14

I just want to be able to use TypeScript and ES6 modules together :c

top level await, es6 modules and typescript with this config working
default tsc --init with couple tweaks
{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "nodenext",
    "outDir": "./build",
    "isolatedModules": true,
    "esModuleInterop": false,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  },
  "include": ["source"]
}

package
{
  "type": "module",
  "scripts": {
    "build": "npx tsc -w",
    "dev": "node --watch build/app.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "mongoose": "^7.0.0"
  },
  "devDependencies": {
    "@types/express": "^4.17.17",
    "typescript": "^4.9.5"
  }
}

import express from 'express'
import mongoose from "mongoose"
import { uri } from './config.js'
import { router } from './routes.js'

const app = express(), port = 3000

app.use(router)
await mongoose.connect(uri)
app.listen(port, () => console.log(`http://localhost:${port}`))

no errors just add .js on imports

While there is no fix from tsc itself (the #11901 has been closed to collaboration since Jul 2018), I had to write this small script called fix-tsc-es-imports that can be integrated into the building process just after tsc.
It adds a .js extension to all relative imports and exports in the code generated by tsc, solving the issue.

Thank you @Higgs1. I will add a dynamic imports fix with string literals on the next forthcoming version. Although, dynamic imports with variables would be out of the scope of the tool. As you mentioned, that is indeed a hack while the tsc team does not fix that in the compiler itself. I'll be glad to deprecate the package as soon as we see tsc doing that job for us.
In the meantime, to deal with dynamic imports with variables I think the best option would be to use tsc as a type checker and type generator, and use Babel's @babel/plugin-syntax-dynamic-import.

Similar to what @danb4r said and done. This issue is important, which is why ts-add-js-extension was made, the strength of this package is that, it can also find whether you are importing/exporting something.js or something/index.js, and it can find whether you are importing/exporting .js or .mjs, you just have to specify the outDir for this package to work, I try not to bind this tool on tsc or anything related to it (reading outDir in tsconfig.json) and want it to be able to run independently. Try it, it should also solve your problem as it covers a lot of cases

Can this be re-opened please? I just hit it when trying out node's new --experimental-strip-types feature... I get to choose between having a working app but LSP errors, a dysfunctional app but no LSP errors, or using CommonJS modules and an LSP warning, that doesn't seem ideal??


[Suggestion] Patch for MinGW and possibly WinXP support

There were several questions about MinGW and WinXP support in discord-rpc (#88, #83, #34), all being closed as "not supported".
Inserting this piece of code into discord_register_win.cpp (instead of old preprocessor blocks) makes it compilable with MinGW as well.
UPD: Wrong solution, causes segfaults on MinGW builds, see comments below and PR #105
// Patch for discord_register_win.cpp
#include "discord-rpc.h"

#define WIN32_LEAN_AND_MEAN
#define NOMCX
#define NOSERVICE
#define NOIME
#include <windows.h>
#include <psapi.h>
#include <cwchar>
#include <stdio.h>

/**
 * Updated fixes for MinGW and WinXP
 * This block is written the way it does not involve changing the rest of the code
 * Checked to be compiling
 * 1) strsafe.h belongs to Windows SDK and cannot be added to MinGW
 * #include guarded, functions redirected to <string.h> substitutes
 * 2) RegSetKeyValueW and LSTATUS are not declared in <winreg.h>
 * The entire function is rewritten
 */
#ifdef __MINGW32__
/// strsafe.h fixes
#define StringCbPrintfW snwprintf
LPWSTR StringCbCopyW(LPWSTR a, size_t l, LPCWSTR b)
{
	a[l-1] = 0;
	return wcsncpy(a, b, l - 1); // does not set the last byte to 0 on overflow, so it's set to 0 above
}
#else
#include <strsafe.h>
#endif // __MINGW32__

/// winreg.h fixes
#ifndef LSTATUS
#define LSTATUS LONG
#endif
#ifdef RegSetKeyValueW
#undefine RegSetKeyValueW
#endif
#define RegSetKeyValueW regset
LSTATUS regset(HKEY hkey, LPCWSTR subkey, LPCWSTR name, DWORD type, const void *data, DWORD len)
{
	HKEY hsubkey = NULL;
	LSTATUS ret;
	if (subkey && subkey[0])  /* need to create the subkey */
	{
		if ((ret = RegCreateKeyW( hkey, subkey, &hsubkey )) != ERROR_SUCCESS) return ret;
		hkey = hsubkey;
	}
	ret = RegSetValueExW( hkey, name, 0, type, (const BYTE*)data, len );
	if (hsubkey) RegCloseKey( hsubkey );
	return ret;
}

// Discord_RegisterW and the rest of the file

It may be not the best solution, but it definetely makes the code compilable with MinGW (not tested to be working though, just finished rewriting it - will test as soon as I write some code to test it with).
The idea is:

The <strsafe.h> header belongs to Windows SDK, and as such, can not be included into MinGW code and/or ported here. The only two functions used from it were simply remapped to <string.h> substitutes.
The RegSetKeyValue API call is missing in WinXP and is not declared in MinGW <winreg.h>, and redefining WINVER macros (as it was done previously) does not help here. It was remapped to a substitute realization that uses two common API calls.

Also, serialization.h contains #pragma declarations meant to supress warnings in MSVS, but they cause warnings in MinGW, so I wrapped them in #ifndefs, like this:
// Patch for serialization.h
#ifndef __MINGW32__
#pragma warning(push)
#pragma warning(disable : 4061) // enum is not explicitly handled by a case label
#pragma warning(disable : 4365) // signed/unsigned mismatch
#pragma warning(disable : 4464) // relative include path contains
#pragma warning(disable : 4668) // is not defined as a preprocessor macro
#pragma warning(disable : 6313) // Incorrect operator
#endif // __MINGW32__

#include "rapidjson/document.h"
#include "rapidjson/stringbuffer.h"
#include "rapidjson/writer.h"

#ifndef __MINGW32__
#pragma warning(pop)
#endif // __MINGW32__

What should I do next with these patches?

@k1-801 can we close this with the merge of #105 ?


Added version to expected labels

What is this PR About?
As per subejct
How do we test this?
TESTING.md doc
cc: @redhat-cop/rego-policies

/lgtm


add WAL for persistence (?)

Maybe add WAL for some sort of on-disk 'persistence' via database reconstruction on startup


Fix generation of trap OID in genTrapType()

Adds a missing "." in front of the "0" when creating the trap OID (e.g. the correct "<IP_ADDRESS>.<IP_ADDRESS>.2.0.1" instead of "<IP_ADDRESS>.<IP_ADDRESS>.20.1" for Oracle Enterprise Manager's "oraEM4Alert"). This was actually fixed in PySMI's original repository for version 0.4.0 (see https://github.com/etingof/pysmi/blob/58f2bf29cccff633af703f319dc237e17e16e3d3/pysmi/codegen/intermediate.py#L497), where the code in question was also moved to a different file (intermediate.py).

Could you merge the branch with develop to have correct version before we add this fix?


Question: How to handle nested, packed module file hierarchies

Often when working with deeply nested modules I reflect the nesting structure in my file hierarchy using .mlpack files
- lib.mlpack = "A\nB\nL"
- src/
    - l.ml/i
    - a.mlpack = "X\nY"
    - b.mlpack = "Z\nQ"
    - a/
      - x.ml/i
      - y.ml/i
    - b/
      - z.ml/i
      - q.ml/i

Now, when using Merlin in such a structure it's often the case that it cannot find modules. Typically I structure things a bit like
src/a/.merlin = "REC"
src/b/.merlin = "REC"
src/.merlin = "REC"

with .merlin in the main directory as
S src
S src/a
S src/b
B _build/src
B _build/src/a
B _build/src/b

Is there a more proper design for helping Merlin to find the right modules in a situation such as this? Thanks!

it's often the case that it cannot find modules

What do you mean?
Also, if the .merlin files in the subdirectories only contain REC you don't have to have them, merlin will look in the parent directories to find a .merlin.

I mean that if I try to, say,
open A.X

in b/z.ml then merlin will report that A.X is unknown but the compile will work cleanly.

Does it tell you that A.X is unbound, or that A is unbound?
I can't reproduce with just this information, I don't know how to compile that. How do you invoke ocamlbuild?

I do invoke ocamlbuild. If you add a file ./lib.mllib = "Lib" and invoke ocamlbuild lib.cma it should build. If you do ocamlbuild lib.cmxa you'll need a few more files.
A live, related example exists here.
When I open this file in emacs and C-c C-x to check for errors Merlin reports that this line has the following error
Error: The type constructor t expects 1 argument(s),
but is here applied to 2 argument(s)

This occurs because it interprets Covariant.S as being defined in src/s1/covariant.ml despite there being a "closer" Covariant.S.
I think that solving either problem ought to solve the other.

Alright, in that particular case you then need something like
$ cat src/s1/.merlin
B ./../../_build/src
B ./../../_build/src/s1
$ cat src/s2/.merlin
B ./../../_build/src
B ./../../_build/src/s2
$ [...]

I think that corresponds to what ocamlbuild has in its path when compiling each of the .mlpack ( @gasche will confirm?).

Ah, interesting. I suppose I misunderstood the merlin REC model.

This is sort of tragic too, of course. Ultimately I have to replicate the entire tree in each leaf...


New versions of contributed libraries are not published for almost two weeks now

Describe the problem
New versions of contribute libraries are not published for almost two weeks now.
Examples are my libraries EthernetENC and UIPEthernet and khoih-prog's libraries TimerInterrupt_Generic and SAMD_TimerInterrupt.
New versions of Keyboard library and Arduino_Braccio_plusplus library are available in Library Manager. Both are in arduino-libraries repository
To reproduce
.
Expected behavior
.
Additional context
No response
Issue checklist

[X] I searched for previous reports in the issue tracker
[X] My report contains all necessary details

all update just now


Remove need for slug, source & picture field in POST /stories

Create slug as you want from title field, juste use alphanumeric lowercase characters and dashes (prevent heading / trailing / consecutive dashes).


tensorflow implementation

Hi,is there a version of tensorflow implementation?

Sorry I don’t have time to implement the tensorflow version.


Adding GPU_BLEND_MULTIPLY_COLOR

This pull request adds GPU_BLEND_MULTIPLY_COLOR, which is functionally identical to SDL_BLENDMODE_MOD (see https://wiki.libsdl.org/SDL_BlendMode).
SDL_BLENDMODE_MOD
    color modulate
    dstRGB = srcRGB * dstRGB
    dstA = dstA

I also omitted value initialization from the GPU_BlendPresetEnum enumerated list to make for quicker editing in the future. This is because
typedef enum {
    A,
    B,
    C
} ABCenum;

is treated identically to
typedef enum {
    A = 0,
    B = 1,
    C = 2
} ABCenum;

by compilers. The same code is generated, but it's now easier to add, say, A2 between A and B without having to manually go through and say B=2 and C=3 now.
I hope that makes sense and that this helps. Keep up the great work on this API!

I'll take another look at this.  The feature is a good one.
The value initialization is intentional in order to preserve value compatibility.  If a new value is added, it should not change the values of the ones that already exist unless a breaking change is acceptable.


How do I set errorPath for Matching Fields Validation Inside repeat section for each row

I have a formly form  and I am programmatically generating the formly configuration based on JSON from API. I need to be able to validate dates within each row by comparing each other.

Currently I am not able to achieve this with errorPath.

I need to be able to use the index and set each row invalid individually. I dont have a way of obtaining the index of the repeated-row inside validator.expression = (control: AbstractControl) => {}

Please advise. Much appreciate your directions.
Minimal illustration of Issue 1 using the matching fields example: https://stackblitz.com/edit/angular-zymk2s

The easy way is to pass the validator though fieldArray https://stackblitz.com/edit/angular-zymk2s-n82ymm another alternative is to return the path from the validator itself in v5.10.0 you can return multi-errors from a single validator
export function fieldMatchValidator() {
  ...

  return {
    password: {
      errorPath: 'passwords[0].passwordConfirm',
      message: 'Password Not Matching' ,
    },
    password1: {
      errorPath: 'passwords[1].passwordConfirm',
      message: 'Password Not Matching' ,
    },
  };
}


Compile Error If data does not have copy constructor

If I compile the following code,
#include <boost/sml.hpp>

namespace sml = boost::sml;

struct data_type {
  data_type() {}
  data_type(const data_type &) = delete;
};

struct test_sm {
  test_sm() {}

  auto operator()() const {
    using namespace sml;

    return make_transition_table(
      *"start"_s = X
    );
  }

  data_type data;
};

int main() {
  using namespace sml;
  test_sm test;
  sm<test_sm> test_sm(test);
}

It gives an error of "use of deleted function" caused by the deleted copy constructor like below.
error: use of deleted function ‘test_sm::test_sm(const test_sm&)’ sm_impl(const TPool &p, aux::false_type) : sm_t{aux::try_get<sm_t>(&p)}, transitions_{(*this)()} {

This did not happen at the revision on 2017/5/30. Is this intentional change?

I am also interested why state machine instance is copied.
operator()() is executed only once, that's good.
In my project I have something similar to data example and the instance is copied many times.


INT-2291 polished broken test

Out of curiosity, how reproducible was this before that added sleep?


Clicking triggers focus ring

Provide a general summary of the issue here
Kooha-2024-10-29-04-48-27.webm
Clicking on elements like <Link> or <Button> causes a focus ring to appear around the element. Clicking and dragging outside of the element will make the focus ring stay even when you let go of the button. You can of course style it so that the focus ring will not be visible, but now it will never be visible even when tab-focusing which of course hurts accessibility.
The behavior occurs both in Chrome and Firefox. Strangely, I can't reproduce it in the preview in the documentation page.
🤔 Expected Behavior?
Behave like a normal native element. Clicking on element should not trigger the focus ring.
😯 Current Behavior
See the video above.
💁 Possible Solution
No response
🔦 Context
No response
🖥 Steps to Reproduce
https://codesandbox.io/p/sandbox/amazing-torvalds-mqjdy6
Version
1.4.1
What browsers are you seeing the problem on?
Chrome
If other, please specify.
No response
What operating system are you using?
Linux
🧢 Your Company/Team
No response
🕷 Tracking Issue
No response

You should add outline: none as a default style for these elements (you'll notice we do for all our docs examples). Similar closed issue: https://github.com/adobe/react-spectrum/issues/6683

Updated the sandbox to include outline: none (https://codesandbox.io/p/sandbox/amazing-torvalds-mqjdy6), but the issue still occurs. Is there something else you need to do?

Thank you, it works pretty well!


Procedural storytelling

Would be interesting to start grinding later stage on generative rooms, generative emerging storylines, character evolution 🧬 by player
There is potential to generate various dungeons as procedurally-generated content.
Probably could be linked with #(voice-narrator) issue
Term backward story sifting is definitely inspiring.
Did smol link surfing, def retrospect interesting stuff
ref

https://www.theverge.com/2021/11/30/22807568/procedural-storytelling-video-games-dwarf-fortress-wildermyth-blaseball
https://sibr.dev/
https://www.kmjn.org/notes/sims2_ai.html The Power of Projection and Mass Hallucination (Practical AI in The Sims 2 and Beyond)
Local intelligence is good enough, at least for something like The Sims. Just focus on making sure everything makes sense in relation to what comes immediately before and immediately after, and players will fill in appropriate long-term stories themselves.
Players find it easier to give specific outcomes rather than traits — answering "likes hiking (y/n)?" is easy, while "x/10 for extrovert?" isn't.
Story Sifting https://mkremins.github.io/publications/Felt_SimpleStorySifter.pdf
https://versu.com/
https://versu.com/about/how-versu-works/
http://intrinsicalgorithm.com/IAonAI/2009/10/aiide-2009-ai-challenges-in-sims-3-richard-evans/
http://intrinsicalgorithm.com/IAonAI/
http://intrinsicalgorithm.com/IAonAI/?s=AIIDE
https://www.routledge.com/Procedural-Storytelling-in-Game-Design/Short-Adams/p/book/9781138595309?utm_source=cjaffiliates&utm_medium=affiliates&cjevent=77b14218534711ec82bc01b30a18050d
Procedural Storytelling in Game Design https://www.goodreads.com/book/show/42479553-procedural-storytelling-in-game-design

I'm a huge fan of procedural dungeons. The nerd in me can't wait until we have the ability to generate a planet, generate a puzzle on that planet, and generate a random item or chest at completion. This could literally be a game you can never fully complete, and would serve as a puzzle piece for others to add to their games, worlds, and experiences.
Definitely keep me updated. Happy to help product manage the effort.


I cant add my video on my readme

I solved my Problem By doing revision of Git and Github Fundamentals.


'Namespace' object has no attribute 'cookie'

Probably an issue with SECRETS.txt.
the file looks like this now: (with the numbers letters altered and the cookie redacted)
uid=100000232323239
cookie=datr=JuOSKadJDmdiU8_gn3djr4B; locale=en_US; c_user=[Redacted cookie]wd=882x749
client_id=88c9g39b

Terminal outputs:

Felipes-MacBook-Air:zzzzz-master felipe$ python fetcher.py
Traceback (most recent call last):
File "fetcher.py", line 8, in
import graph
File "/Users/felipe/Downloads/zzzzz-master/graph.py", line 6, in
import flap
File "/Users/felipe/Downloads/zzzzz-master/fbapi.py", line 4, in
import fetcher
File "/Users/felipe/Downloads/zzzzz-master/fetcher.py", line 25, in
class Fetcher():
File "/Users/felipe/Downloads/zzzzz-master/fetcher.py", line 31, in Fetcher
'cookie': secrets.cookie,
AttributeError: 'Namespace' object has no attribute 'cookie'

Yep it's probably an issue with SECRETS.txt. Look at line 14:
with open("SECRETS.txt") as f:
    for line in f:
        vals = line.strip().split('=', 1)
        setattr(secrets, vals[0].lower(), vals[1])

It splits each line at '=' and sets the left part as the key and the right part as the value.
If you just want to get it running you could replace secrets.cookie at line 31 with your actual value which is:
datr=JuOSKadJDmdiU8_gn3djr4B; locale=en_US; c_user=[Redacted cookie]wd=882x749 client_id=88c9g39b (with the numbers letters altered and the cookie redacted)

The mistake is in your SECRETS.txt file. The cookie' field must be something like: cookie='cookie values here'`.
Plus your SECRETS.txt looks really different from mine, make sure to copy it correctly from your browser.


Merge development onto development_3.0

Description
Merge development (the 2.x branch) onto development_3.0.

Thanks Gilles, seems that it was indeed accidentally based on the wrong commit. I've updated it accordingly. I haven't documented the conflict resolution (yet) as your link above is broken.

Sorry, I used the wrong branch name in the link to my merge. I've edited my message above.

I've fixed the missing include in cpp_dummy_build (although I can't find any previous mention of this include in the git history, so unclear if this is a merge conflict or something that was missed). If it was missed, possibly it would be better as a separate commit - but I don't think it really matters.
This should address everything except the MPS enum naming issue - I'm looking at this in #4306

config_psa.h was added to cpp_dummy_build.cpp in the development branch in #4159. There was a conflict in the merge here with the adjacent removal of certs.h. The correct resolution of that conflict was to keep config_psa.h added in 2.x and not re-add certs.h removed in 3.0.


Error on raise exception

There seems to be a typo on the following line, but this line would only cause an if the frequency table specified could not be found.
Technically it is valid syntax, but the object does not exist.
https://github.com/MarkBaggett/freq/blob/48010fd45a11d4257e1a758b49193a30addd9442/freq_server.py#L201

Fixed.  Thanks.


[Sprig App] My First Game

Author name
Author: CodingMasterGirl
About your game
What is your game about?

Press S

I'm gonna close this since it seems like just the starter template, but feel free to make another pull request when you've built your game!


Ct workspace

Deleted my other pull request, cleaned up the CSS and added a donation link that will go to the footer.

Hi Caitlin! It looks fairly good to me from just grabbing the raw files from your branch, but I'll wait for Raman to make any comments if there's any conflicting css lines.
Additionally, I think the branch that you're currently working off of is behind the main branch- backup your files first to a different folder (just in case), switch to your working branch, and run git pull origin main. You'll probably get a CONFLICT message, like below:

When you open up your local files in vscode it should give you all the incoming changes from the git pull origin main command. You'll have to to merge together all the main branch's lines with your changes, save, then run...
git add .
git commit -m "message here"
git push origin branch_name
...to both update your branch's files with the most up to date files from the main branch, and add on your changes.


encoding problem with unicode character

from the version 6.1.1 we experienced text encoding issues from author field (it can be any field I guess). The text we expected is Teknikens värld but what we got back is Teknikens VÃ¤rld. I believe there is a fix in changelog affects that

Yes. I figured out similar behaviour.
@dukemai Can you confirm if this comes from iptc ?
You need to parse with options `` …
Reason / Fix;
The iptc parser reads a Latin1 but does not convert it to utf8 …
After line 86 let val = this.chunk.getLatin1String(offset + 5, size)
it could be fixed with
val = Buffer.from(val, 'latin1').toString('utf8'); …

I'm encountering an issue that may be related to this. The Caption field appears to use the wrong encoding, while ImageDescription uses the correct encoding:
  Caption: 'Carrer de SepÃºlveda',
  ImageDescription: 'Carrer de Sepúlveda',

Yes. I figured out similar behaviour. @dukemai Can you confirm if this comes from iptc ? You need to parse with options like {mergeOutput: false, xmp: true, iptc: true, icc: true} …
Reason / Fix; The iptc parser reads a Latin1 but does not convert it to utf8 …
After line 86 let val = this.chunk.getLatin1String(offset + 5, size) it could be fixed with val = Buffer.from(val, 'latin1').toString('utf8'); …

sorry I missed that question. yes, you are right about the error


add onComplete listener

Hi!
This little PR of mine will add the ability for a user to globally configure a callback for all the requests done through vue-resource.
It is useful for example when the user wants to set up a single error handling logic in a single place and never thought about it again. This is actual reason why I would like to see such functionality, not a made up one.
I would really appreciate you taking a look at the code. This is my first glance under the hood of vue-resource, so I might've done something dumb, if so, please comment.
Thank you.

Oh, I just happen to find a way to achieve the same result by simply pushing the new interceptor, so that no modification in the library itself is needed.
Sorry for the PRs )


Remove extraneous **

@diogoff : Thanks for your contribution to the Azure documentation! The author, @stevestein, has been notified to review your proposed change.

@diogoff - thanks for the fix!
#sign-off - this PR is OK and ready to merge.


Remove defaultProps from StatusBar

See parent issue #31601
Expected Result
defaultProps removed from StatusBar

Hi can I take this issue?

@Fannolo assigned!

Is the development still happening? if not can I work on this

Is the development still happening? if not can I work on this

Hi @yasirunilan, sorry for the late reply, the development is actually completed, I am doing some additional checks before asking @lunaleaps to merge it

@lunaleaps can we close this issue? 😄

Thanks for the reminder!