[pom] Add checkstyle with last jdk < 11 usage at 9.3 and basic setup

Try 2...
Restores attempt at #337.  @mathieucarbou asked this be reopened.  In reviewing converstation I feel like there is a bit of confusion so trying to reset here and its wordy and probably a bit opinionated.  Feel free to shake this out however needed even if shelved.  Thanks.
All IDE's by default are generally setup for legacy support (like 10+ year old java).  There is really only one valid code style which is googles in modern usage from checkstyle.  Yes sun exists but that is left over legacy support.  In any usage, less restrictive or more restrictive, a base needs to be setup.  That base in this case is verbatim google rules as shipped in checkstyle (9.3 in this case).  I could have opted to not even drop the file here like this but did so for customizatino needs.  It does not adjust or attempt to address any repository considerations on either more restrictive or less restrictive.  It is import to come in clean without making customization so that the history can better show what cusomization we apply and allow for easier maintenance upgrades from checkstyle versions as those will change and extensibility here is using their identical file so we have to be really clear on what we add, modify, or delete so its easier to upgrade that part.
Ok back to this.  This setup is not a final requirement by any means.  It just checks and outputs what it doesn't like, it does not fail the build nor attempt to as the code doesn't have any specific error violations just warnings.  Again with restrictive vs less restrictive, those decisions are not really made yet.  This just opens up what might be for consideration and we adjust fromt here until we are satisfied on reduction of the warnings and if we really want to force failure on warnings.  That may in fact end up looking more like the Intellij setup added in recent days and this thus does no harm.
I see the imports were reverted back mostly in recent commits which fail general guidelines (you can check by impsort-maven-plugin).  Usage of any IDE in fact is rather meaningless and generally not modernized.  No one needs to change a thing in their IDE though.  The plugins applied like adding impsort in a separate PR will always ensure imports are in respected order - default or otherwise without any requirement from a contributor to change any defaults they like.  That is the more broad point.  We cannot at any single repo level expect anyone to comply with rules nor would we remember specifics if we work over lots of repos.  Every case I've seen like that ends up in education of the contributor moreso than picking up new changes.
So to circle that all back, what is the point.  Slowly introducing new plugins into the build that start to build a foundation for how we expect the repo to look.  This will take several iterations to accomplish.  Each will be rather loose on restrictions.  Its mainly to start getting a solid baseline then you add automation plugins to the mix that start to auto enforce these.  The the only rule for a contributor is that they build before submitting a PR or we automate an action to write back like 'site' already does but against incoming PR to do the same.
The more broadly adopted here already was in favor of Intellij.  That's great but that leaves out others that use Netbeans, Eclipse, simple editors, etc.  Personally I don't use Intellij for a whole host of reasons.  Its like apple vs google or apple vs microsoft or x vs y.  Regardless there are flavors that people like and if they are forced to come in making all kind of IDE related changes or consessions, they will be less likely to contribute.  But if that is left up to their own and we just control as much in automated fashion as possible, everyone wins.
hint: on impsort, this is why a separate PR had been raised, it used the generialized defaults of that plugin to apply.  Its fine either way but checkstyle will disagree here.  Also I believe I noted this mostly on first PR including having a separate PR for 120 charactor spacing not 100 as alignment would get messed up using that older legacy resolution (years and years of java, came from 60 up to 120 over time...google isn't there yet but they should be, in fact most monitors typically used probably can occomodate 160 now without scrolling off the screen).
Anyway all that said, this really boiles down to at least highlighting issues in the build.  I believe far more plugins in general are needed: pmd, spotbugs (the successor of findbugs), and various others that can ensure a lot but we need to start somewhere ;)

A few comments:

There is a massive amount of overlap between official styles.  OSHI uses what was the "Sun" conventions with a change from tabs to spaces.  I looked into switching to google and the differences were few (2- vs. 4- char indent, line widths, and treatment of switch/case indents).  I was very close to installing a maven plugin that actually enforced/formatted the code, except (by design) it would not allow any configuration such as line width or indent.
This brings us to spotless-maven-plugin.  This is a great plugin that does all the formatting for you using the configuration you specify.  Submitters can write code in whatever format they want, and just run mvn spotless:apply before they commit, and it gains all the benefits of a project code standard.  That plugin allows you to specify the google format (with some tweaks if you want) or, in my case, I have exported my eclipse format xml file to my project where:

eclipse users can configure directly
intellij users can configure using a plugin that uses eclipse format files
spotless-maven-plugin can read the identical file and use it for formatting

With regard to @mathieucarbou's comment about shortcomings of google format, please consider palantir-java-format.  It is developed by the authors of google format but is more modern (proper treatment of lambdas, 120-char line width) and has Intellij plugin.  Spotless can take this format as well.
In light of all of the above, I am not fond of using checkstyle to enforce formatting.  Let's use IDE plugins and spotless to automate that and make it easy.  Let's keep checkstyle to non-format-related checks.

have also never found it possible to fix every checkstyle issue.

You can add suppressions to stop warning on specific checkstyle issues that you can scope by packages, class names or even down to line numbers (or range of them).  Or remove rules from the format that you don't want to use.  Then you could enforce it if you wanted.
My point was more separating style checks (e.g., variable naming/capitalization rules, etc.) from "formatting" which is largely about spacing, brace positioning, wrapping and indentation.
One other thing to consider, see https://EditorConfig.org which IntelliJ reads and has rather simple rules.  See https://github.com/oshi/oshi/blob/master/.editorconfig for my config

Like I said, I am not against the using a style. The main advantage of using a common set of rules is also to help reduce the diff when sources are modified and help conflicts solving also, plus readability.
I am against some rules the Google style contains, like the column size, enforcing some wrapping, not correctly aligning, etc. IntellIj default does a better job at formatting. And some of the rules Google Style forces, like wrapping and alignment, empty lines (i.e. after a class name declaration.) have to be left up to the dev to his discretion for readability. IntelliJ has at least 60% share of the mark. Most of Java devs are using IntelliJ and most IDEs by default are easily configurable to adhere to some basic rules like spaces, wrapping, curly brace place, indent, trailing space, no star import, etc. Besides, with an EditorConfig file, loading a style is now made easier.
The Google style changes A LOT from IDE's default, but besides that, worsens it. So this reduces the easiness to contribute and also code with a default IDE's format, and it reduces readability. The problem with a plugin that is automatically formatting is that it will erase any intentionally  formatted code for readability, except if we limit the rules it applies. Also, I suspect that the Google rules are done in a way that they could be coded and applied to many IDEs, like simple ones, because the rules it enforces are not smart at all compared to what IntelliJ can do with alignment, wrapping and grouping imports.
For import: the Google style does not enforce a lot of grouping, I guess to simplify... I personally find that grouping helps readability and besides that, when a source file is updated, grouping also can help the diff and conflict solving. For imports, I would not enforce anything. I would just ask that people prevent their IDE to auto-format / auto-import. Here, the goal would be to help reduce merge conflicts and reduce PR diff. If someone creates a new class with all imports sorted alphabetically, it's fine for me. But when the source file will be modified next, we have to make sure the whole import section does not get re-organized.
So I am not against using a style, I am against using a style that is enforcing too many things, especially things not needed and that are not bringing any value.
Here is what I would do:
I would instead use a plugin like checkstyle or anything else that will check for what we want / do not want, and provide in the project some style examples to load in the idea if wanted.
I personally don't care if curly are on a new line or end of line. It doesn't matter to me: it won't change how I read the code or  what I think about the person writing the code. I strongly prefer that the person who is creating a class creates it in a way he is used and focus on what he wants to do instead of how it has to format his code or be bothered by how it reads.
Some part of the code is also more complex and more subject to be formatted in a specific way for readability reasons or to help conflict solving / diffing, and no plugin should reformat that or go against that.
What is important is to enforce rules that have an impact when diffing or conflict merging
we want:

tab size: 2
indent: 2
continuous indent: 4
some basic common grounds like space between closing parenthesis and curly, no space between method name and opening parenthesis, etc.

we don't want:

star import
trailing space
auto organizing imports before commits
auto format before commit

Not sure if there is more to add...
About the reformat I did yesterday
This is to put a common ground / zero state that should pass any rule enforcement that we put.
Some of unecessray or problematic formatting seen with Goole style:

too intense wrapping, leading to unreadable code, especially for classes like HeaderType or long method declarations
incorrect alignment when wrapping for method parameters
rewriting of comments // foo
unnecessary wrapping of assignments
adding empty lines at end of files or after class declaration
unnecessary field annotation alignment
unnecessary ternary operator indentation
bad alignment for multiple resource declarations in a try-resource block
unnecessary wrapping and indentation of stream calls

closing as I don't feel the value is here.


It is better to use the repository field in Cargo.toml

To allow Crates.io , lib.rs and the Rust Digger to link to it. See the manifest for the explanation.

change homepage to repository in cargo.toml


mpop: 1.4.3 -> 1.4.4

Motivation for this change
https://marlam.de/mpop/news/mpop-1-4-4/
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

This pull request has been mentioned on Nix community. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/12

(minor touchup of pname, after doing some by request for #60189)


add msvs 2017 support

Based on https://github.com/nodejs/node-gyp/pull/1952#issuecomment-549631126 this isn't necessary? cc @joaocgreis

after opening the PR I saw that these changes already there in GYP3. However, as long as you use the node-gyp this is needed.

This shouldn't be needed, VS detection is not done by GYP but in https://github.com/nodejs/node-gyp/blob/master/lib/find-visualstudio.js.
@dothebart what issue did you see that needs this? Is the detection in node-gyp not working for you? Can you paste the output of a failing node-gyp rebuild --verbose here?

Ah, I don't compile V8 for nodejs - its https://github.com/ArangoDB/ArangoDB - so I don't have this file.
I now continued with gyp3, which has this. So if you don't want it, close it.

I guess we'll have to land something like this or remove autodetection from the GYP side, but I'd rather wait until we figure out how GYP will be managed here. @dothebart thanks for opening this PR and trying to help.

hm, asking a heretic question - how do you run .js before having a ready compiled V8?

I'm not sure I understand your question... Here in node-gyp, Node.js is required to run, so V8 is always already compiled.
For compiling Node.js itself in https://github.com/nodejs/node/ a different mechanism is used. It uses vswhere from the command line: https://github.com/nodejs/node/blob/ed401236f6988c6ad62a21dbbf808da83782bee0/vcbuild.bat#L247

ah, nice. a shellscript to tell the environment autodetection infrastructure about the infrastructure to work around the autodetection.
Is Gyp3 the way ahead?

There's discussion about the way forward in https://github.com/nodejs/node-gyp/issues/1791. There was a PR to change to GYP3 https://github.com/nodejs/node-gyp/pull/1845 but it was closed. From what I see, it looks like we'll be maintaining GYP here specifically to be used in node-gyp at least for a while.


Fix some minor grammatical errors.

Add hyphens and articles where necessary.
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/gothinkster/realworld/blob/master/CONTRIBUTING.md#commit

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[x] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Thanks: you're now a contributor to RealWorld! 🎉


Question: How can flux with helm support auto detect latest docker image

Hi, I am following the using.md tutorial using the flux-helm-test repo.
I tried fluxctl release --controller=test:fluxhelmrelease/mongodb --k8s-fwd-ns=flux --update-all-images and it was not able to detect the latest docker image (the standalone flux was able to).  It results in this broken commit https://github.com/tlvu/flux-helm-test/commit/00916a3185a935a2476a99ab04b9055dc0bbb0a3 (notice the bad update image: bitnami/mongodb:_).
How can flux with helm support auto detect latest docker image?

It's only fluxd that's doing any latest image detection; i.e., it would work the same with or without the helm operator. What you might be seeing is that the mongodb image has a tag _ which points at the most recent image. If I look on dockerhub, I do not see that tag though. This bears a bit of looking into.

If I look on dockerhub, I do not see that tag though.

Ops! I was looking at the official mongo image. The bitnami image does have a tag _: https://hub.docker.com/r/bitnami/mongodb/tags/
I'd put a semver filter on that resource, so it is restricted to the images with a proper version.

Oh so the tag _ actually exist !  Wow misleading tag !
Closing this issue as I just retested with my own image and --update-all-images is working:
$ fluxctl list-images --controller=default:fluxhelmrelease/bc-release-service
CONTROLLER                                  CONTAINER    IMAGE                                                            CREATED
default:fluxhelmrelease/bc-release-service  chart-image  bcdocker-staging-rnd-artifacts.intelerad.com/bc-release-service
                                                         |   1.0.1-lvu-testing                                            26 Sep 18 21:40 UTC
                                                         |   latest                                                       25 Sep 18 18:35 UTC
                                                         '-> 1.0.0                                                        24 Sep 18 13:47 UTC

$ fluxctl release --controller=default:fluxhelmrelease/bc-release-service --update-all-images -vv
Submitting release ...
CONTROLLER                                  STATUS   UPDATES
default:fluxhelmrelease/bc-release-service  success  chart-image: bcdocker-staging-rnd-artifacts.intelerad.com/bc-release-service:1.0.0 -> 1.0.1-lvu-testing
Commit pushed:  9b77caa
Commit applied: 9b77caa


fix(angularls): also use new_root_dir for probe locations

Fixes #300.

Why not fix things upstream in lspconfig so everyone benefits?

Not sure if this could be added to lspconfig. We install a local typescript installation alongside the LSP server. If this were to be added to lspconfig it'd probably end up looking something like:
function get_cmd(probe_dir)
  -- Detect if typescript is installed globally, if it is, determine its file path
  local global_tsserver = a.wait(job(...))
  -- Determine where ngserver is installed globally, use it for "--ngProbeLocation" because the language service is a direct dependency to ngserver
  local global_ngserver = a.wait(job(...))

  return { "ngserver", ... }
end

This is how VSCode bundles their angular "extension" by the way. It ships with typescript installed.

And so what was added in this PR is how lspconfig currently works. Prior to this PR we'd only use the bundled typescript and angular dependencies

I tried to do the auto-detection here: https://github.com/neovim/nvim-lspconfig/pull/1462
It's possible to test the project local packages to see if a project local typescript is installed

It's possible to test the project local packages to see if a project local typescript is installed

This is actually how it's configured now. You can apparently provide more than one location to probe, so we provide (in this order, because that's how VSCode does it 🤷 ):

the lsp installer location where typescript is installed
the workspace directory


Set-SPO not working as expected

We tried on executing the 'Set-SPOSite -Identity $_siteUrl -LockState Readonly' but we keep on having the issue below. Was there anything changed since? It was working before as we executed it yesterday.

Set-SPOSite : https://tenant-my.sharepoint.com/personal/user_com is a OneDrive for Business site collection. The only valid parameters for this type of site collection are '-Identity', '-AllowDownloadingNonWebViewableFiles', '-AllowEditing', '-ConditionalAccessPolicy', '-DefaultLinkPermission', '-DefaultSharingLinkType', '-DisableCompanyWideSharingLinks', '-LimitedAccessFileType', '-LockState', '-Owner', '-SharingAllowedDomainList', '-SharingBlockedDomainList', '-SharingCapability', '-SharingDomainRestrictionMode', '-ShowPeoplePickerSuggestionsForGuestUsers', '-StorageQuota', and '-StorageWarningLevel'.

Hope you can help us with our issue or guide us if we missed something on our end.

@officedocsbot assign @yogkumgit

@Oweeboi011
Hello,
This issue may have been fixed with the latest version of the module.
I recently experienced a similar error when changing the StorageWarningLevel for a Group site.
The version was 16.0.19814.12000.

Get-InstalledModule -Name Microsoft.Online.SharePoint.PowerShell -AllVersions

After updating to the latest version (16.0.19927.12000),  the same command works.

Update-Module -Name Microsoft.Online.SharePoint.PowerShell

For my tenant using the latest version, -LockState ReadOnly also works.
Would you please check and update your module version?

If you use SharePoint Online Management Shell, you can get latest version here.
https://www.microsoft.com/en-us/download/details.aspx?id=35588

Hello @Oweeboi011 how are you? I could verify in my lab what @kefujino kindly shared here, using the latest version of the module, it worked without issues.
Hope this info helps you.

@get-itips  Thank you very much for the contribution and sharing this explanation. @Oweeboi011
Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

all
it is not working and we have updated the module and it same issue. we have tried to increase quota and failed

all
it is not working and we have updated the module and it same issue. we have tried to increase quota and failed

Please kindly open a support ticket in your tenant, they will able to help you.

after updating SP module to newest one my error went away :)

And, it appears to be back in the latest version
Get-Module microsoft.online.Sharepoint.powershell | select name,version

Name                                   Version
----                                   -------
microsoft.online.Sharepoint.powershell 16.0.20717.12000

PS D:\Scripts> Set-SPOSite "https://tenant-my.sharepoint.com/personal/$Domain" -LockState NoAccess
Set-SPOSite : https://connectqutedu-my.sharepoint.com/personal/wahry_qut_edu_au is a OneDrive for Business site
collection. The only valid parameters for this type of site collection are '-Identity',
'-AllowDownloadingNonWebViewableFiles', '-AllowEditing', '-ConditionalAccessPolicy', '-DefaultLinkPermission',
'-DefaultSharingLinkType', '-DisableCompanyWideSharingLinks', '-LimitedAccessFileType', '-LockState', '-Owner',
'-SharingAllowedDomainList', '-SharingBlockedDomainList', '-SharingCapability', '-SharingDomainRestrictionMode',
'-ShowPeoplePickerSuggestionsForGuestUsers', '-StorageQuota', and '-StorageWarningLevel'.
At line:1 char:1
+ Set-SPOSite "https://tenant-my.sharepoint.com/personal/$Domain ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Set-SPOSite], ServerException
    + FullyQualifiedErrorId : Microsoft.SharePoint.Client.ServerException,Microsoft.Online.SharePoint.PowerShell.SetSite


Add aria-label to "Back" button on Multistep Donation forms

Because the button has no text itself, it's not considered accessible. We can fix this with an aria-label
Example Page: https://gov-oco-flst.pantheonsite.io/advancing-ocean-justice/

Done


test: failing for duplicate VMID in same metaInfo

related: https://github.com/nuxt/nuxt.js/issues/4282
Whether or not that feature should be supported by vue-meta is another thing to discuss.

It should yes


setup: Python 3.11 support

Add support for Python 3.11

Coverage: 81.098%. Remained the same when pulling a5b7d25682492b4bc61f8d8ac2ea58c5f560f191 on py311 into 23fd01600057b0df3a9bf02e98fad423455c9f00 on master.


Switch workers to Fedora to support newer macros

Since people started using new macros RPM functionalities that are not available (and probably won't be) on CentOS Stream 9, let's switch our workers to Fedora to help in this situation.
Long-term, we need to research how to provide matching environment: https://github.com/packit/research/issues/219

Since people started using new macros that are not available (and probably won't be) on CentOS Stream 9, let's switch our workers to Fedora to help in this situation.

It's not about macros (that can be handled e.g. with mock or just by preparing a suitable environment for rpm), it's about new rpm features that won't be available in older/more stable distributions.
When we switch to rpm 4.20, spec files using %patchN syntax will become unparseable, however that shouldn't be a problem on Fedora where all packages have been mass-converted, though it could be an issue on CentOS Stream.

Please, try running tests before deployment.


Offer option to resolve module path maps in emitted code

Search Terms
paths
tsconfig.json
compilerOptions
ts-node
node
cannot find module
Suggestion
Per #10866, module path maps are not resolved in emitted code. This means that if you attempt to run the emitted code with node, it will be unable to resolve those paths and the server will not start.
Current solutions:

use browserify or webpack to bundle the output -- this is an unfortunate solution given that it'd be the only reason for me to bring in one of these tools, as I've managed to build and deploy apps using just the typescript compiler. This blog post from the TypeScript team even strongly recommends using a TypeScript toolchain:

https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/

For that reason, we feel tsc and the tools around the compiler pipeline will still give the most integrated and consistent experience for most projects.

use a tool like module-alias. This is a bit gross as it requires duplicating the path maps, and inserting code at the root of your server.

Proposed solution:
Offer a compilerOption, something like resolvePaths, that resolves aliased paths to their relative paths.
Use Cases
So that I can continue to meaningfully use the paths property in tsconfig.json.
Examples
Please see the example in #10866.
Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[ ] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)

I think you want #16577.

Hey Daniel, thanks for the quick response.
I don't think this is a duplicate of #16577 -- this issue deals with aliases not being resolved to their relative paths on build. I should have been clearer in the description rather than linking to an old bug.
E.g, given this directory structure:
tsconfig.json
common
  - helper.ts
server
  - index.ts

Where tsconfig.json maps common to @common, like this:
compilerOptions: {
  ...
  "paths": {
    "@common/*": [
      "./common/*"
    ]
  }
}

And this code in server/index.ts:
# server/index.ts
import { foo } from '@common/helper';

When TSC outputs this, it keeps the alias rather than resolve it to the relative path. And node doesn't know how to resolve this.
Unfortunately, I don't think you can use tsconfig-paths when running node against JavaScript files. I use tsconfig-paths to run my server in development, e.g;
node -r ts-node/register -r tsconfig-paths server/index.ts
But this does not work:
node -r tsconfig-paths server-build/index.js
My request is that the TypeScript compiler offer an option to resolve the aliases to relative paths so that node can properly run the outputted code. Otherwise, the "paths" feature in tsconfig.json is somewhat unhelpful, as it requires bringing in additional tools to reconcile the output.

Check out this gist:
https://gist.github.com/deejayy/aa5f0cde76dc29f6b4127e60e74be2f2

A simple use case that tsconfig-paths doesn't really help with:

I have package @companyName/some-shared-frontend-stuff that's written in Typescript
I want to use path aliases internally @companyName/some-shared-frontend-stuff
I want to use that package in @companyName/site-number-1 that's written in JS with Webpack compiling

Right now, the only way to do this is to have a Babel compile step happen with @companyName/some-shared-frontend-stuff, which complicates dev work pretty painfully because I can't just use tsc -b --watch with npm link and instead I have to have a separate file watcher that re-does Babel builds when things change.

@DanielRosenwasser provided my previous comment makes sense, can we remove the duplicate flag or discuss further?

@DanielRosenwasser pinging again. Any chance this could go on the roadmap for 3.2?

Until officially supported, I've created a solution that does not require any dependencies nor babel. It also fixes .d.ts files (currently only if they are in the same directory as output. declarationDir support can be added too. PRs are welcomed!).
https://github.com/joonhocho/tscpaths

@joonhocho there are existing third party solutions, the idea is to avoid them entirely.
@DanielRosenwasser pinging again -- this is still marked as a duplicate and it shouldn't be. can we re-evaluate?

@DanielRosenwasser please reevaluate this issue. The proposed solution is simple, and has nothing to do with the reasons you mentioned for rejection - this doesn’t align with any 3rd party tool, it just makes the TS internal paths option work like 99% of people expect in nodejs. Please consider this.

@andy-ms could I get your eyes on this issue? I think Daniel errantly resolved this as a duplicate a while ago, but per my explanation above (https://github.com/Microsoft/TypeScript/issues/26722#issuecomment-417020795), it's not.
I think given the reactions to this FR and the original issue (#10866), it would be a well received addition to TS.

I think it's unlikely that we would change the module specifier you wrote when emitting -- #16577 is an existing issue that asks for that kind of functionality, and if we ever did add that then maybe we would take a look at this too.

@andy-ms ah my mistake I read through the issue more and understand how this is a dupe. Thanks for taking a look.

It's so different from 16577, and more important!
While this issue and https://github.com/microsoft/TypeScript/issues/16577 look similar in terms of "customizing emitted code on module paths", I think there is a subtle difference between the two and I'd like to ask for reopening this issue as its own.
Let's say I have the following import in my typescript code
import helper from "@utils/helper";`

and in tsconfig.json I have set:
"paths":  {
   "@utils/*": [ "src/interal/tools/utils/*" ],
}

The problem with this one is, there is an actual piece of information, (rather than just a .js extension like https://github.com/microsoft/TypeScript/issues/16577), that is getting lost.  It's because tsc just emits the same path as following:
const helper_1 = __importDefault(require("@utils/helper"))

and the piece of information that @util is actually pointing out to somewhere specific in my codebase (i.e. src/internal/tools/utils) is swallowed by the compiler!  Unlike the .js extension issue, there is no way on earth that one can infere this mapping and fix this code, only by looking at the output of the compiler.

Exesting Third Party Solutions
To solve this issue, I need to either re-enter the same mapping manually for the consumption of my JS Loader via something like module-alias (funny, I'm already doing it once for ESLint!) which requires having multiple entries in the codebase for the same concept, a terrible practice; or I should use a tool like tsconfig-paths that reads tsconfig.json and does what compiler is failing to do!
It's interesting to me that for this very problem, tsconfig-paths has got to 500K downloads/week!  In the mean time, all the tickets asking for this simple functionality have been closed here: https://github.com/Microsoft/TypeScript/issues/16640, https://github.com/microsoft/TypeScript/issues/18951, https://github.com/microsoft/TypeScript/issues/18972, https://github.com/microsoft/TypeScript/issues/19453, and so on!

Proposal
It's really simple.
tsconfig.json already has 89 flags.  Let's add the 90th one as --resolveMappedPaths (or something similar) which, at the time of compile, will replace any mapped path (coming from the "key" side of the property in the paths object) to its destination ("value" side of the same property!)
So my tsconfig.json would be:
   "compilerOptions": {
      "module": "commonjs",
      "esModuleInterop": true,
      "target": "es6",
      "noImplicitAny": true,
      "moduleResolution": "node",
      resolveMappedPaths: "true"
      "..."

It can also be a property on an overloaded per-path-basis config, e.g.:
"paths":  {
   "@utils/*": {
       "resolveOnCompile": true,
       "target": [ "src/interal/tools/utils/*" ]
   },
}

+1

+10086

For production apps after a tsc build.
I have created a TS Paths replacer in Go which is pretty fast and that addresses the custom paths issue.
After it's applied you only need to run your app node main.js.

@joseluisq Thanks! But @DanielRosenwasser I don't get it why we don't get a compiler flag to resolve the path. Just to make the path-feature work we have to usw webpack or another bundler. It does not work with tsc.
You say "it's our main goal not to change the generated JS code" but path-maps with tsc breaks the code!!!!
I have two options - Use webpack for this problem to solve or stay with those ugly, long, import path statements...

You say "it's our main goal not to change the generated JS code" but path-maps with tsc breaks the code!!!!

Path mappings are meant to reflect the behavior of whatever is actually resolving .js files. The idea is not to break your code, but to reflect the behavior of something like webpack's resolve.alias or AMD's paths field.

I don't get it why we don't get a compiler flag

Because a compiler flag doesn't actually relieve us of the burden of the complexity of a feature - it just makes it harder for us to think about.

@DanielRosenwasser Thanks for your answer!

the burden of the complexity of a feature
For this particular case??? Seems not sooo complex to me.

My main problem is that I really like what tsc gives me - multiple output files! Every TS-file produces a JS counterpart. That's cool. Readable, understandable and nice. That's what I use for all of my libs. I use webpack for the main application - OK.

is not to break your code
But this is what tsc produces without the help of WebPack - shouldn't tsc produce valid AND runnable code just out of the box???

I can choose between two options.

 (AND it destroys the great TS user experience)

but to reflect the behavior of something like webpack's resolve.alias

But when you use that in webpack, the resulting build actually works. When you use path mapping in TS and use the TS compiler, the resulting build doesn't work.

+1 for this, same issue here. We're using TSC only for type-check and generating d.ts files. The rest is Babel. In Babel we're resolving our aliases fine, but the generated d.ts files will still have the alieses in the copiled code. I also don't understand why this issue have to be closed.

+1

+1.....

@wintercounter >I also don't understand why this issue have to be closed.
Nobody does! Is this really OpenSource????
Microsoft blocks this feature in a very dictatorial manner

Also wondering - this is really making a theoretically nice feature (having nice imports) completely useless.
I mean I don't have any Idea how hard this is to implement but from a naive though it's just s/@alias/realPathFromTSConfig ... no?

Some people need to learn to read.
The issue is closed because it is a duplicate.  The original author indicated that they understood it as such.  When the original author agrees it is a duplicate, it is a duplicate, no matter what you think and #16577 is still open people!

I agree with your first statement (so please go through the comments). Most of the people doesn't consider this as a duplicate and neither do I. The mentioned issue is a whole different topic and that's the main reason this thread could grow as huge as now.

If it is a different issue than the OP, who agreed it was a duplicate then open a new issue that isn't a duplicate that better describes the problem/proposal because it is a different issue...

I went through all the comments of that issue and find no relevance to our
problem.
On Thu, Aug 22, 2019, 00:16 Kitson Kelly<EMAIL_ADDRESS>wrote:

If it is a different issue than the OP, who agreed it was a duplicate then
open a new issue that isn't a duplicate that better describes the
problem/proposal because it is a different issue...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/TypeScript/issues/26722?email_source=notifications&email_token=AAHLJQAEHCFEIKQO3LPESCTQFW5DVA5CNFSM4FSCEI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD43JE5Q#issuecomment-523670134,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHLJQEAQ6AP75R544A4HBTQFW5DVANCNFSM4FSCEI7A
.

@kitsonk Are you sure you red correctly?
@dannycochran nailed it ONE!!!! year ago: https://github.com/microsoft/TypeScript/issues/26722#issuecomment-417020795
What should we do to get this feature - start a petition?? It can't be so hard to solve this problem.
In my opinion it's a philosophical, MS internal, debate that holds back this feature (BTW we shouldn't call it feature - it solves ab bug. Using only tsc to generate code, breaks the app/lib if you use path mappings)
However, (imagine me on my knees), PLEASE add this feature (solve this bug)!

I can understand the team concerns if they have technical reasons to don't implement the feature.
But if TS provides path aliases at development time why those are not also supported in building process via tsc? Why I need a third-party dependency for a TS feature?

It's been two months since I posted a proposal above.
The situation we are in is like going to McDonald's and asking for a burger without a bun.  Then, in a big surprise, you hear "we are not going to cook that thing" and "oh, it's similar to the request of other customers who wanted a veggie burger with yellow bell pepper and avocado."  Unfortunately, none of them are accurate, and I can unblock myself by buying a burger and tossing away the buns manually.  But, due to the extra overhead and the shocking way I am treated, I'll probably reconsider visiting there again in the future.
Same is here.  People in the Open Source Community totally understand if a request has less priority than other works.  However, keeping a clear request with an accurate proposal "closed as duplicate" and not caring at all can hurt.  It hurts the emotions of the current customers  of the platform (developers) at first, but then such demoralization will eventually lead them to shop elsewhere in future.  That's when it might ultimately hurt back the community/project/team.
At the end of the day, what makes a project alive is just how users of the project feel they are treated. There are tons and tons of dead projects and dead packages that people stopped using because no one hears them (just hear them and acknowledge them) when they have a legit request.  And it's totally rational -- as an architect or senior software engineer in charge of a big project you don't want to invest 6 months on something in future and then when you face a problem that hunderds of others are facing too, you see the community has closed the door with "WE DON'T CARE" sign, instead of "Oh, we hear you.  That's right.  Let's democrazie it and post a 'Help Wanted' sign on this to see who will volunteer. :)"

To recap:
Is what we want a duplicate of the issue that marked as duplicate?
Absolutely NOT.
They call fall into the same category of "custom module specifier", just the way you can put chicken and burger in the category of "food". :)
In fact, it was @andy-ms who mentioned that internally they are thinking about a dependency of implementation:

I think it's unlikely that we would change the module specifier you wrote when emitting -- #16577 is an existing issue that asks for that kind of functionality, and if we ever did add that then maybe we would take a look at this too.

It's like saying when we start serving chicken with lettuce then we will serve burger with no bun.  Sure, it's your call internally how you want to build dependencies.  But it doesn't mean I should now sit and wait for chicken with lettuce!
Is this a breaking feature?
Absolutely NOT.
We are asking for a new flag next to the existing 89 ones.
Is this a random irrelevant just-fancy feature?
Absolutely NOT.
There is no way that you can natively use path mapping in TypeScript without using a third-party for this problem.  And without path-mapping if you ever want to move around your src/components/forms directory, you need to change 100 files.  Or if you want to include a component in another one you'll need to walk barefoot using ../../!
Is this a new problem to solve from the scratch?
Absolutely NOT.
There are already a lot of third-party solutions just for this problem!
Is this going to be so new and hard to do in TSC world?
Absolutely NOT.
TSC provides path-aliases at the development time, it's just the way the output should be created.

Again, I have unblocked myself using a custom burger from Burger King!  And it's going to cost me 5 minutes to copy/paste and set up the same custom third-party solutions in any new project.  (Already done twice!)
I'm just watching here to see how Microsoft is treating its Typescript users and that will definitely shape my thoughts about Typescript for any future technical decision I'll make. :)
Thanks!

slowly backs away from keyboard

How is this thread so long without a single example of what the proposed transform is?
I'll also paste what I wrote elsewhere: Our general take on this is that you should write the import path that works at runtime, and set your TS flags to satisfy the compiler's module resolution step, rather than writing the import that works out-of-the-box for TS and then trying to have some other step "fix" the paths to what works at runtime.
We have about a billion flags that affect module resolutions already (baseUrl, path mapping, rootDir, outDir, etc). Trying to rewrite import paths "correctly" under all these schemes would be an endless nightmare.

IOW if there's some way where TS could allow you to write the path that you want emitted, that will always be the preferred solution

Hi folks -- OP here. Maybe chill a little. The vitriol / victimhood / name calling is really bizarre for a product that consistently releases new features and incorporates community feedback. FWIW, my solution to this was to stop using tsconfig paths and live with the ../../.. here and there. It's been fine. My codebase has not imploded.

How is this thread so long without a single example of what the proposed transform is?

@RyanCavanaugh  This comment kind of illustrates what path we'd want emitted.
This alias:
# server/index.ts
import { foo } from '@common/helper';

Should get resolved to:
# server-build/server/index.js
const helper_1 = require('../common/helper');
const foo = helper_1.foo;

That presumes an outDir of server-build, which, when built, would look like this:
server-build
  common
    - helper.js
  server
    - index.js

This is also closely related to #30952, which is basically the same thing as @dannycochran and @eyedean have noted above but for .d.ts files.

@dannycochran what rules should tsc follow to determine to rewrite?
# server/index.ts
import { foo } from '@common/helper';

Is the @ suggesting some sort of semantic meaning?  That directly conflicts with Node.js resolution logic with namespaced packages.  What would the tsconfig.json look like?

Also, if based on your first comment you expect paths to contained overloaded functionality, that would be a breaking change for a lot of other users of TypeScript who are trying to model what their runtime environment is looking like, the original intention of the poorly named paths argument (which was to model configurable loaders like AMD and SystemJS, and therefore copied the misleading name of such a configuration option there).
So you would need to propose introducing some sort of other variable that said "ignore the existing meaning of paths and resolve and rewrite the paths relative to something else", but also the feature would need to address where it isn't possible to express a relative path at runtime, and those who would need to mix runtime mapping and build time rewriting.

Also, if based on your first comment you expect paths to contained overloaded functionality

The functionality described in @dannycochran's comment is how paths already works. Something like this...
baseUrl: ".",
paths: {
  "~/*": ["src/*"]
}

...is already used by lots of people to make Typescript reflect the common or even default behavior of other Javascript tooling (the built-in ~ alias in Parcel is effectively identical to the above for most use cases, for example).

Is the @ suggesting some sort of semantic meaning?

This is presumably...
baseUrl: ".",
paths: {
  "@common/*": ["src/*"]
}

The functionality described in @dannycochran's comment is how paths already works.

But it doesn't cause the import specifier to be rewritten.  Taking away just the ability to remap locations of modules that will be located different during runtime, which is what the intent of paths is today needs to co-exist.  Just putting a flag that says "rewrite" module specifiers wouldn't be a good idea, because as soon as you do that, someone will say they want remapping and rewriting at the same time.

This is presumably...

I think if this has any chance, presuming wouldn't be sufficient.

So a simple question: How we should ship libraries while using paths? Short answer: We can't by default.
To be fair, Babel doesn't support such either, I have to use a separate plugin to resolve my alieses. BUT at least it is able to have a plugin!

That's exactly the point. Currently it doesn't work. It only can work if those paths are being resolved.

Yeah, that is what I am struggling with here too...
Potential use cases for a library:

One that will run under node.  If this case, best to leverage node module resolution fully instead of trying to invent your own.  node doesn't have a configurable loader.  That is life.
Running in a browser or node as a standalone library.  If this is the case, you should use some sort of bundler, like rollup, webpack, Parcel, etc.  Using paths might help make bundling easier, but unlikely, best to leverage your packager to output the standalone versions you need.  Being a complete build tool is not a goal of TypeScript.
Running browser only, using an AMD or SystemJS loader.  You have one design time paths of which you have to inform your consumer on how to integrate that into a larger loader configuration at run time, but likely can releverage your paths.
Loading ES Modules directly in a browser (or Deno).  Use import-map (or the polyfill) and again, essentially the paths.

tsc is not a bundler, never will be a bundler (or a full featured build tool)... that means it will never know enough, nor want to know enough to properly re-write the module specifiers.  It understands Node.js resolution, but again, that is design time mirroring of what is expected to be valid at runtime.  For tsc rewriting can only be write for a very narrow set of uses cases and most of the time it would be just wrong.
Just repeatedly saying "its a bug, fix it" without addressing the specific questions raised to any proposal in really not going to make anything move forward.  Proposing something that a) preserves  existing functionality that people are depending on and b) can be usable with exemplar use cases is about the only way this will move forward.

For my specific case the biggest issue here are d.ts files. No bundler is
going to help to "bundle"/resolve their imports.
I understand the concerns behind implementing such feature but seems like
it's a valid use case for many of us. If tsc's plugin system would provide
us an interface where we can manipulate the emitted path that would solve
the problem for many of us I think. tsc can stay pure that way.
On Tue, Aug 27, 2019, 06:30 Kitson Kelly<EMAIL_ADDRESS>wrote:

Yeah, that is what I am struggling with here too...
Potential use cases for a library:

One that will run under node. If this case, best to leverage node
module resolution fully instead of trying to invent your own. node doesn't
have a configurable loader. That is life.
Running in a browser or node as a standalone library. If this is
the case, you should use some sort of bundler, like rollup, webpack,
Parcel, etc. Using paths might help make bundling easier, but
unlikely, best to leverage your packager to output the standalone versions
you need. Being a complete build tool is not a goal of TypeScript.
Running browser only, using an AMD or SystemJS loader. You have one
design time paths of which you have to inform your consumer on how to
integrate that into a larger loader configuration at run time, but likely
can releverage your paths.
Loading ES Modules directly in a browser (or Deno). Use import-map
(or the polyfill) and again, essentially the paths.

tsc is not a bundler, never will be a bundler (or a full featured build
tool)... that means it will never know enough, nor want to know enough to
properly re-write the module specifiers. It understands Node.js resolution,
but again, that is design time mirroring of what is expected to be valid at
runtime. For tsc rewriting can only be write for a very narrow set of
uses cases and most of the time it would be just wrong.
Just repeatedly saying "its a bug, fix it" without addressing the specific
questions raised to any proposal in really not going to make anything move
forward. Proposing something that a) preserves existing functionality that
people are depending on and b) can be usable with exemplar use cases is
about the only way this will move forward.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/TypeScript/issues/26722?email_source=notifications&email_token=AAHLJQHBP5BWREGJBL2Q2W3QGSUVVA5CNFSM4FSCEI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5GOA6Y#issuecomment-525131899,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHLJQHD64R4EUVR5RZAWF3QGSUVVANCNFSM4FSCEI7A
.

A new Node.js proposal, proposal-pkg-exports, adds a new import field to package.json that seems to cover the most common use case there. If it would be accepted and TypeScript would use it for type resolution (I guess it can be tracked as a part of #33079) it would be possible to create local aliases in a simpler and more compatible way (webpack might support it as well), while paths option would be able to keep it's current meaning - reflecting non-standard runtime resolution behavior.

I am sorry to see that this issue is not receiving the attention it needs after over a year. This is a real problem and I don't understand why @eyedean 's proposal has fallen on deaf ears.

We're listening and have repeatedly, repeatedly, repeatedly explained in multiple threads why this proposal goes against our main goals about how module paths should work in TypeScript.
Not getting what you want doesn't mean the other person in the conversation isn't listening.

Thanks for you replay @RyanCavanaugh. Would you mind pointing me to one of the places where I can read up on the ideas behind module paths?

https://github.com/microsoft/TypeScript/issues/26722#issuecomment-524375687

There's also primary design goal number 7: Preserve runtime behavior of all JavaScript code
https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
An import statement is JavaScript code, so unless it needs downleveling, per our design goals, it should be left alone.

Frankly, design goal 7 seems to indicate the exact opposite reaction. You have set up compiler config, you are changing your code for that compiler config, now the compiler is breaking your JavaScript and thus changing your runtime behaviour. Thats exactly why everybody wants these paths rewritten.
I appreciate all the efforts of the Typescript team, but the given reasons for preventing a change that is comparatively speaking so trivial and has, again relatively speaking, so little possible negative impact while such a big part of the userbase is asking for it is just baffling to me.

You have set up compiler config, you are changing your code for that compiler config, now the compiler is breaking your JavaScript and thus changing your runtime behaviour.

The only situations that it breaks behaviour is when you never had a valid behaviour to begin with.  It just isn't magically fixing it for you, and that upsets you.
paths was introduced to mimic the potential runtime behaviour of different loaders, so you could write your TypeScript in a way that would match the runtime configuration.

I appreciate all the efforts of the Typescript team, but the given reasons for preventing a change that is comparatively speaking so trivial and has, again relatively speaking, so little possible negative impact while such a big part of the userbase is asking for it is just baffling to me.

Then make a proposal that would work.  A proposal would include what gets emitted and the logic.  People so far have only proposed that some sort of magical flag be added to the configuration that will read the developers mind and emit something, but haven't expressed some sort of valid emit.

Frankly, design goal 7 seems to indicate the exact opposite reaction. You have set up compiler config, you are changing your code for that compiler config, now the compiler is breaking your JavaScript and thus changing your runtime behaviour. Thats exactly why everybody wants these paths rewritten.

Our position is that you should write the path that works at runtime, and set up your config however is necessary so that TS can understand what those paths resolve to. What's being requested is the opposite: that the developer writes a path other than the one that works at runtime, and that the config would tell TS what path to write instead. That's exactly what's being proposed in this comment, for example.
It seems like what several people in this thread have done is:

Start with working relative paths
Add path mapping to their tsconfig to invent new module paths that don't work at runtime (e.g. @Component/foo)
Change their files to import from these fictional paths
It doesn't work at runtime because the runtime path is invalid
Feature request: TS should resolve my fictional paths for me

The correct solution is to just stop at step 1 where everything worked and you were writing the path you wanted at runtime! Which seems to be exactly what you're saying in your comment.
Am I taking crazy pills here?

The only situations that it breaks behaviour is when you never had a valid behaviour to begin with. It just isn't magically fixing it for you, and that upsets you.

I had a whole thing written here, but @RyanCavanaugh has put it much more succinctly.
You are correct, this is what most people have done here, because paths are primed for this. Everybody who doesnt want to use the awfulness that is most tools that surround JS compilation at this day and age just want to compile with TS directly, and would just love paths, and then there they are, staring you straight in the face but refusing to take the last and easiest step. And the first time you notice, is after you have made it all compile.
And frankly, clearly this is how many people not only want to use this feature, but intuitively assume that this is exactly what it is for.
I wouldnt say you are taking crazy pills, but why not simply enable this trivial feature, when there is so little downside? That seems crazy to me!
But lets get to @kitsonk`s suggestion:
After writing all this i realised that i have basically rewritten a proposal from way up in the thread, but hopefully in a clearer way, with an added example.
I will say that I have a little experience with the complexities of compilers and compiler options for programming languages, but nowhere near the amount you guys have, obviously. But i completely fail to see how this proposal add any significant complexities to thinking about the language or the compiler, as mentioned here
And while I dont condone the tone people have taking in the later portions of this thread, I can understand and share their frustration that a simple and easy to implement proposal is getting such blanket refusal, on what, respectively, seems so very little reasonable grounds.
Anyways, here goes nothing.
A simple proposal
Disclaimer
First off, I have not seen(which is not to say it doesnt exist) any reasons why this would not work, so im outlining the most simple and least intrusive thing I can think of to make the most basic case work nicely that would cover what I think is 99% of what the people in this issue yearn for.
The import paths can already be resolved internally in TS,  otherwise it could not type check, which means the logic for checking wether an import path has a matching rewrite in the tsconfig is there, and working.
Terms

ResolvedPath: A path in an import statement that has a matching entry in paths

Add a singular flag --rewritePaths which changes emitting behaviour such that an import statement with a ResolvedPath  is using that path for emitting. It should change .ts file endings to .js.
It defaults to false.
All other behaviour remains untouched. If no paths are set, the flag becomes an effective no-op. This is only in effect if outDir is being used of course, if everything gets turned into a single file, imports are not relevant.
This behaviour should not be impacted by any other compiler config. AFAICT.
Example
All following file paths are of course relative to the --baseUrl.
Assuming paths to look like this:
"paths": {
    "helpers": ["helpers/index.ts"]
}

This file, located at  "library/complicated/deep/path/source.ts"
import { helper } from "helpers"
helper()

should emit as
import { helper } from "../../../../helpers/index.js"
helper()

if paths was empty, it would emit as
import { helper } from "helpers"
helper()

Please let me know about any issue or oversight, I'm happy as can be to have productive discussion about this.
Also a final disclaimer: it is rather late over here in germany, so forgive me for typos or bad phrasing.

@RyanCavanaugh You are not taking crazy pills, but I think the hangup is here:

Add path mapping to their tsconfig to invent new module paths that don't work at runtime (e.g. @Component/foo)

It does work at run time if you're running with ts-node, which is a fairly common way of running TS code locally before shipping to a deployed environment, where it's compiled and no longer works. I can't really think of another place with TS compilation where the compiled code cannot execute because of runtime errors that otherwise don't occur when using ts-node -- maybe if you set the target too high for a node or browser environment?
@kitsonk I don't think these comments are totally fair given some of the previous communication from the TS team:

Being a complete build tool is not a goal of TypeScript.
tsc is not a bundler, never will be a bundler (or a full featured build tool)...

From this blog post:

Using the TypeScript compiler is still the preferred way to build TypeScript. While Babel can take over compiling/transpiling – doing things like erasing your types and rewriting the newest ECMAScript features to work in older runtimes – it doesn’t have type-checking built in, and still requires using TypeScript to accomplish that. So even if Babel builds successfully, you might need to check in with TypeScript to catch type errors. For that reason, we feel tsc and the tools around the compiler pipeline will still give the most integrated and consistent experience for most projects.

I don't think it's unreasonable for folks to expect that tsc is the only thing they need to build and deploy code. If the TS team strongly disagrees, I'm not sure they've sufficiently marketed that idea.

Then make a proposal that would work. A proposal would include what gets emitted and the logic. People so far have only proposed that some sort of magical flag be added to the configuration that will read the developers mind and emit something, but haven't expressed some sort of valid emit.

I'm not sure I understand what's problematic with this example: https://github.com/microsoft/TypeScript/issues/26722#issuecomment-524405693. I added a tsconfig.json-- you mentioned you weren't sure how the @common would be resolved, sorry I had included that part in a previous comment.

Here are some questions I have about this feature:

What happens when an import resolves to a .d.ts file? Should these paths be rewritten too?

Should it be possible that importing a/b and a/c would write a/b but not a/c as a result?

Does this apply to all imports that start with a non-relative name, or just those where path mapping was invoked?

Does a path mapping that only changes the case of a path qualify under the above?

What if I only want to rewrite some of my paths?
Should this treat symlinks as opaque, or transparent?
Does this apply when an import resolves to an ambiently-declared module, but that import path also has an applicable path mapping?
Should paths in emitted .d.ts files get rewritten? Why or why not?

What about reference directives?

What happens if an import resolves to a .ts file in node_modules? Should TS write out ../../node_modules/foo/index.ts ?

If not, by what logic is this excluded?

What happens under --allowJs when an import resolves to a .js file?

Again though, I still consider this a non-starter feature, because the statement
import a from "b";

is an ECMAScript statement, and per design goal 7, when it doesn't need to be downleveled, we do not change it. This is no different from saying TS should cause a runtime error when a divide-by-zero occurs: We don't change the semantics of JS code.

I think at this point it's obvious that we have a philosophical problem, and NOT a technicial one. : )
In fact, my technical proposal has been sitting here for 3 months now receiving tens of upvotes from users.  In the meantime, the third-party solution for this exact issue has passed 500,000 downloads per week earlier this month!

It seems like what several people in this thread have done is:
• Start with working relative paths
• Add path mapping to their tsconfig to invent new module paths that don't work at runtime (e.g. @Component/foo)
• Change their files to import from these fictional paths
• It doesn't work at runtime because the runtime path is invalid
• Feature request: TS should resolve my fictional paths for me

The correct solution is to just stop at step 1 where everything worked and you were writing the path you wanted at runtime!

I am sorry @RyanCavanaugh, but I smell the same dictatorship that another user mentioned in this thread earlier.  I don't think when there is such a simple request, with millions of downloads for an alternative per month, you can tell what people fictionally WANT is WRONG.  That's not how technologies grow and gain popularity.
Putting all the details behind, developers simply want to have absolute paths in their imports instead of a train of ../../../.. that breaks so many things if you move a folder.  That's as simple as it.

All being said, what we have heard so far is:
Case A) People shouldn't do it
I'm sorry, just because you are in charge of official team behind an open source project it doesn't mean you can dictate people what they are allowed to WANT, if it's a valid and sane popular request.  (Reminds me of the same stance Microsoft had in early 90's, which led to the birth of Open Source and Linux!)
Case B) It doesn't fall under the responsibilities of tsc
I'm sorry, but tsc already handles it during compile/type-checking time very well using paths.  In fact, as @dannycochran mentioned above, if you guys want developers to rely on tsc as the preferred way to build, please make life easier for everyone.
Otherwise, the brand behind TypeScript would become "there is an official tsc compiler, but it doesn't include what it takes to turn your working *.ts to working *.js flawlessly, unless you download this and this and that third-party package."
Case C) Oh, if we do this, then we need to do that, and rewrite half of the compiler
No!  All people, and I am talking about millions of people, want is SUCH A SIMPLE CAPABILITY TO BE ADDED UNDER AN OPTIONAL FLAG.  Optional means (I think I ought to mention it) that it's going to be off/disabled by default.  So unless someone actually goes and turns this new knob, it's not going to do anything.  Thus, not a breaking change.
We can sit and argue for eons, but at the end of the day, Done is better than Perfect!  And here, undone (plus the attitude we are seeing here) is hurting the reputation of a growing technology.
Thanks.
PS.

Here are some questions I have about this feature:

I am not sure if these are questions to improve the comprehensiveness of the propsal, or just to show off that oh it's difficult/unwanted-by-the-official-team.
Let's stay positive, anyway!  Instead of going into the weeds, I can tell that the User Story is as simple as:
I have @model/*" : [ "src/model/*" ], under paths in my tsconfig.json.  I just want any import userData from "@model/user/data" to work as expected from anywhere in my codebase.  Currently it works during compile-time but doesn't work during run-time, as you know.
I bet this is 98% of what people (at least those millions of customers of the third-party) want.  It's up to you to decide whether these 98% customers should wait until we get the answer to all the little details of what the other 2% want or not.
Thanks for your time anyway.

All being said, what we have heard so far is: ...

Many of those things have not been said.
Let me try to be as clear as possible:

TypeScript doesn't change the behavior of JavaScript code.
import  statements are JavaScript code.
Therefore TS is not going to modify that statement.

It's not even about scope, it's about one of the ten things we said we will never do, and intend to keep not doing it. People have told me dozens of times that we need to violate those principles for their particular feature or else TypeScript is doomed to failure.

I am not sure if these are questions to improve the comprehensiveness of the propsal, or just to show off that oh it's difficult/unwanted-by-the-official-team.

People keep shouting about how this is trivial, therefore must be done, as if we're afraid of doing the work. It may be simple to implement, but that doesn't mean it's conceptually straightforward, and ultimately we care a lot more about the conceptual load of a feature that our users have to endure than the difficulty of putting together a PR to add the feature.

Wouldn't it also conceptually conflict with import maps?

Here are some questions I have about this feature:

Another one I'd like to add is handling of dynamic import syntax. Should they be transformed as well? If yes, that might present a very surprising behavior:
import('path'); // works
const path = 'path';
import(path); // fails

If no, that might be against the specification, since both static and dynamic imports use the same abstract operation for specifier resolution.

Wouldn't it also conceptually conflict with import maps?

As the paths feature stands now, it reasonably models import maps.  It is how the feature of SystemJS and AMD was standardised in a browser context.  It doesn't conflict conceptually any more because of it, but it underlines that TypeScript doesn't want to get into the business of re-writing module specifiers, because that is effectively a runtime only concern.

As I mentioned before the solution would be an overhaul to the plugin
system. Another pain point which the community has complaining about for
years now. It would save a lot of headaches fro you guys if we would be
able to customize the compiler on our own through plugins and it would
easily tackle such cases as this one.
On Fri, Sep 20, 2019, 04:04 Kitson Kelly<EMAIL_ADDRESS>wrote:

Wouldn't it also conceptually conflict with import maps?
As the paths feature stands now, it reasonably models import maps. It is
how the feature of SystemJS and AMD was standardised in a browser context.
It doesn't conflict conceptually any more because of it, but it underlines
that TypeScript doesn't want to get into the business of re-writing module
specifiers, because that is effectively a runtime only concern.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/TypeScript/issues/26722?email_source=notifications&email_token=AAHLJQGE4HWI2OCOPAL6HU3QKQVUPA5CNFSM4FSCEI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7FKBWY#issuecomment-533373147,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHLJQEH4Q6YKFQ5RXLVEC3QKQVUPANCNFSM4FSCEI7A
.

+1

I think this is really important, as TypeScript declarations for libraries are essentially broken if you use absolute paths. We then need to manually fix them, or use a tool to go through and correct paths.
If my library internally imports ./src/folder as folder (which is the same as ./folder), this works fine. I can use Rollup, Webpack, etc. to update the paths as appropriate.
But I can't do the same for d.ts files. The result is that TypeScript (in a user's project) thinks my library is importing a package called folder and fails.
For the JavaScript itself, I understand the argument for not changing output.

I spend all day trying to figure out what wrong with my setup and why paths aren’t resolved in outputted js files. Makes this feature almost useless and very confusing, since it processes NOT WORKING output for NodeJS. Please add some option to resolve paths that tsc already knows internally and bring the end to this struggles. It wouldn’t break anything if it will require option to enable resolution.

I also ended up here after searching for why my emitted code doesn't have the paths I expected. After reading through this thread, I think I agree with what seems to be the unpopular position of not changing the paths in the output. There's just too much to consider, and I don't see how tsc could possibly account for every variation of build process out there, not to mention things like automated tests, etc.
What I would suggest to the tsc devs is to make the documentation a little clearer here: https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping
Right now, that section could be interpreted to mean that emitted code will have the paths resolved, but really the setting just makes it so that we can use other tools for module resolution and allow TypeScript to understand what those imports mean. The documentation not being clear about that seems to have led to some confusion and expectations among a lot of users, myself included.

There's just too much to consider, and I don't see how tsc could possibly account for every variation of build process out there, not to mention things like automated tests, etc.

@mrobrian what is suggested here multiple times (and has received many upvotes and support from other developers) is to add an optional flag that supports the simple absolute paths to relative conversation in the output, just as it's already doing in the compile time.
The two bold words here are:

Optional, so it wouldn't break anything.  Only people who want it will use it as an experimental flag.
Simple, as simple as what https://github.com/dividab/tsconfig-paths does.  I understand we can make a beast out of this to support 100% of the use cases; but just providing the simple 20% of it will satisfy 80% or more of the needs.

Thanks.

+1

Just gave up and change 72 file in one of my packages. Moved back from module path to relative path imports.
IT LOOKS SOOOO UGLY - All those ../ It makes me wanna puke!
It is tilting at windmills - I'm broken. MS you won - Congrats! :cry:

Here are some questions I have about this feature:

What happens when an import resolves to a .d.ts file? Should these paths be rewritten too?

Should it be possible that importing a/b and a/c would write a/b but not a/c as a result?

Does this apply to all imports that start with a non-relative name, or just those where path mapping was invoked?

Does a path mapping that only changes the case of a path qualify under the above?

What if I only want to rewrite some of my paths?

Should this treat symlinks as opaque, or transparent?

Does this apply when an import resolves to an ambiently-declared module, but that import path also has an applicable path mapping?

If "yes", this means adding a .d.ts file to your compilation could break the runtime output of your program. This is unprecedented.
If "no", then how does a user predict whether a given import will be rewritten?

Should paths in emitted .d.ts files get rewritten? Why or why not?

What about reference directives?

What happens if an import resolves to a .ts file in node_modules? Should TS write out ../../node_modules/foo/index.ts ?

If not, by what logic is this excluded?

What happens under --allowJs when an import resolves to a .js file?

Again though, I still consider this a non-starter feature, because the statement
import a from "b";

is an ECMAScript statement, and per design goal 7, when it doesn't need to be downleveled, we do not change it. This is no different from saying TS should cause a runtime error when a divide-by-zero occurs: We don't change the semantics of JS code.

@RyanCavanaugh  I think what people ask for could be a rather simple solution and has nothing to do with the existing compile-time module resolve process. I think what people want is:

Only apply this feature to the current compile result (i.e. after all existing compile logic is complete and just before emitting the result)
Works as the simple string replacement without involving any complicated path resolution processes.
e.g. for the config below:

{
  "compilerOptions": {
    "pathAlias": {
      "a/b/c" : "../x/y/z",
      "@e/d/f/": "../../e/d/f",
      "../../u/v/w/": "../dist/"
    }
  }
}

The compliler should complete all existing compilation logic and do the followings before emitting the result:

check if any imported module names in the compile result meet the following criteria:

fully match or start with the string "a/b/c/" or fully match string "a/b/c"

If so, replace the string a/b/c in the module name with "../x/y/z" in the compile result that is about to emit (without validating or resolve the path ../x/y/z).
e.g. require("a/b/c/moduleA") becomes require("../x/y/z/moduleA")
require("a/b/c") becomes require("../x/y/z")
import xxx from "a/b/c/moduleA"; becomes import xxx from "../x/y/z/moduleA";

fully match or start with the string "@e/d/f/" => replace with "../../e/d/f"

e.g. require("@e/d/f/moduleB") becomes require("../../e/d/f/moduleB")
import xxx from "@e/d/f/moduleB"; becomes import xxx from "../../e/d/f/moduleB";

fully match or start with the string "../../u/v/w/" => replace with "../dist/"

e.g. require("../../u/v/w/moduleC") becomes require("../dist/moduleC")
import xxx from "../../u/v/w/moduleC"; becomes import xxx from "../dist/moduleC";

Moreover:

this module name rewritten logic should not only apply to .js but also .d.ts files that are about to emit.
this feature should work independently. i.e. whether or not existing path mapping feature or project references feature is on or off doesn't impact the on/off of this feature as this feature works as the last step of the compilation process just before emitting.
this feature should apply to any /// <reference types="xxx/xxx/xx" /> as well

I think the simple logic above should avoid most of the issues you mentioned in your post as this module name rewritten logic is triggered by string match and processed by string replacement without any module resolution process involved.

It also achieves what we ask for using babel & babel-plugin-module-resolver (just in case anyone looks for alternative solution):

install @babel/cli  & babel-plugin-module-resolver

yarn add --dev @babel/cli babel-plugin-module-resolver

Create .babelrc file at the project root with the following content:

{
    "compact": false,
    "retainLines": true,
    "minified": false,
    "inputSourceMap": false,
    "sourceMaps": false,
    "plugins": [
        [
            "module-resolver",
            {
                "root": ["./dist"],
                "alias": {
                    "abc/src": "@a/bc/dist"
                }
            }
        ]
    ]
}

Build your project by: yarn tsc -b && babel dist -d dist

This assumes you output all build files to dist directory.
It will, firstly, compile your project using typescript compiler tsc
Then, pass all compile result in dist directory through babel and replace the module name and output back to the same dist directory

Unfortunately, babel won't touch *.d.ts files in the dist directory.
It will be good that this feature can be implemented by tsc or make it possible to create a plugin of tsc to do so.

Curious if anyone has found a solution for rewriting import alias in *.d.ts files? We're using babel to build TS to JS which resolves the alias correctly, but it's broken in *.d.ts.

Yes, https://www.npmjs.com/package/tsconfig-paths

@wintercounter Hm. Doesn't seem to work if your tsconfig.json extends from another config. In my project, we extend from a dependency config and tscpaths blows up.

The author did a limited implementation just to support the basics, but I
think it'd be easy to add support for extends. Make a PR if you have time.
On Wed, Jan 8, 2020 at 5:00 PM Tom<EMAIL_ADDRESS>wrote:

@wintercounter https://github.com/wintercounter Hm. Doesn't seem to
work if your tsconfig.json extends from another config. In my project, we
extend from a dependency config and tscpaths blows up.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/TypeScript/issues/26722?email_source=notifications&email_token=AAHLJQBLU7OCXGYZOC6C2ITQ4X2BDA5CNFSM4FSCEI7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEINBRAA#issuecomment-572135552,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHLJQHWFLAQHJPBTQQK4RLQ4X2BDANCNFSM4FSCEI7A
.

We took this to several design meetings and discussed this to death, and we're sticking with the "JS is JS" design philosophy that has driven TypeScript since its origination.
I'm going to lock this because it's a long thread and our typical experience is that these threads go in circles when it takes more than a few minutes to read the thread. As usual, I'd implore anyone to actually read all 81 comments here, as we ourselves have done multiple times, before filing new issues related to the matter.


Problem: ledger-at-height query not working for blocks above canonical tip

This issue was resolved with this PR: https://github.com/Granola-Team/mina-indexer/pull/459


Click events on custom overlay still going through to map points of interest underneath

I still want to be able to click on POI too but they interfere with buttons in my OverlayView component. I've been researching all over the web and can't find a good solution. I was wondering if anyone here has a solution.

I opted for the InfoWindow instead, I'm not sure what is going on with the OverlayView component, at least in my use case, it is not registering as even being there in relation to the mouse cursor

I think I will

I think I will use an InfoBox with these settings options={{ closeBoxURL: ``, enableEventPropagation: false }}

Hello @jamesjsewell I have the same issues with OverlayView, did you manage to have your own display with InfoWindow or do you have to go with the default close button and fancy margins?


Make brain development poster for Cam Brain Fest

Brief: Discuss human brain development - what we can see at different ages and how we care about brain structural changes during adolescence.
Panels to include:

Measuring myelin in cortex - including video
Measuring how myelin changes during adolesence - inc video
Some pictures of brains at different ages - eg: 4, 7, 10, 14, 20?

Point being that you can't see huge changes all the way through...but you can when you look carefully

[ ] Talk to Ursula in Mackey lab about making some beautiful pictures from PING?

Also need to check about following up with the stem cell group

Sent off to co-authors and looks good 🎉


Windows cygwin support

Evaluate and implement necessary features for cygwin / windows support.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 2 Feb 2010 at 7:11

1.5.6 has improved support for cygwin - hopefully enough for now :)


Compare to CellRanger

While we have no intention of performing our analysis with CellRanger, it would be nice to have a quick (ha!) comparison of its results to Alevin and Kallisto.
This will likely involve making a Dockerfile for CellRanger, as there is not currently an available dockerfile (licensing). It should be possible to create this dockerfile in the github package repository and keep it private, but I am not sure how this will interact with nextflow. Another possibility might be to pass the binary in with the other data files; this might be simpler for the limited runs we expect.

Just a note to add that the bones of this are covered by #31 and #34. The general "comparison" is covered in #35.

Closed by #45


Swipe up and down gestures?

Description
Yet i couldn't find any way to implement swipe up or down gestures.
For example, i would like to swipe up with three fingers to open a menu to open Apps, or swipe down to open a drop down terminal.
Is there already a way to use swipe up and down?
If not so, this would be a useful feature

https://github.com/bulletmark/libinput-gestures
https://github.com/maurges/wzmach

as above


Fix some regex issues

This should fix failures when strings with non-floating times do not match with regex

@paketo-buildpacks/nodejs-maintainers Please take a look


Package Initialization Error

Diagnostics
Request: GET https://api.teletype.atom.io/protocol-version

Versions
Teletype version: v0.13.3
Atom version: 1.30.0
Platform: darwin

Fixed.

Thanks for the report!

Fixed.

Just to clarify, do you mean that you only saw this error once or that you did something to make the error go away?
In any case, I'll go ahead and close as a duplicate of #372 so you can subscribe there for updates if you'd like. If you can, please let us know if you're consistently seeing this error or if you saw it just once. It would also be useful to know if you access the internet via a proxy.


K3s aio

follow up to, and depends on: https://github.com/wolfi-dev/os/pull/4106
this removes the confusing k3s-embedded image (details in ^), and removes the poorly named k3s-images in favor of k3s-aio.
inlines the description for what k3s-aio is in the image's config
re: aio naming. I'm open to suggestions if this doesn't seem descriptive enough! there's no "upstream" verbiage to go off of here so I made something up.

My only naming suggestion is "allinone" is more descriptive than "aio" (if that is indeed what it stands for)

done! ptal


avoid skipped tests with testthat 2.0.0

As of 2.0.0 of testthat any test_that in which an expect_xxx is not called results in a report of an empty test. Also nested test_that(test_that(expect_xxx)) results in empty tests.
This PR cleans that up in all cases except test-size.
For test-size, we have various test_that calls where we do eval(code) and in some cases there is no output and in others there is a warning.  There are 63 of these with 17 giving warnings, so for now I am not going down the rabbithole of distinguishing these cases as there is no expect_xxx that will handle either a warning or no output.

Also worth noting that I did a manual scan of the various output produced by tests under testthat 2.0.0 and earlier testthat, and it looks like this testing is consistent with earlier testthat.


Support image relocation

Images referenced by a CNAB bundle MAY be relocated , for example by copying them to a private registry. This process results in a mapping file:
{  "gabrtv/microservice@sha256:cca460afa270d4c527981ef9ca4989346c56cf9b20217dcea37df1ece8120687": "my.registry/microservice@sha256:cca460afa270d4c527981ef9ca4989346c56cf9b20217dcea37df1ece8120687",
  "technosophos/helloworld:0.1.0": "my.registry/helloworld:0.1.0"
}

That mapping file should be mounted into an invocation image at: `
The spec further says:
The run tool MAY use this file to modify its behavior. For example, a run tool MAY substitute image references using the mapping in this file.

We should enhance porter to enable a relocation file to be provided and mounted into an invocation image,  then also modify the porter runtime so that anything in the relocation file can be used within the execution of a bundle operation. Ideally, if we implement #501, people that build bundles that reference images can simply refer to them like {{ bundle.images.SOMENAME}}, like in a call to the helm mixin or some other mixin that needs to use images, and then Porter will helpfully provide them with the correct reference.

@carolynvs, @jeremyrickard and I discussed putting this back in the Backlog for now.  As of writing, our main needs lie in bundle archiving and bundle publishing (from an archive) which may publish bundle images to a new registry but currently can do so with updated digests/shas.  Therefore, as this ticket (and image relocation in general) brings in a more complex approach to republishing (most pertinently, preserving digests which will go in tandem with forthcoming security guarantees), we've decided to delay this work.

Also see related ticket discussed as part of this area of work: https://github.com/deislabs/porter/issues/687

I believe with the new cnab-to-oci version, the relocation mapping is generated for us on a pull, so we can just inject it into the invocation image. #708 will handle wiring it up inside of the porter runtime manifest.


Create optiface initial feature set.

When optiface is forked to start a new project, the implementer should of course define their features in the implementer code.
What features are common to every project, and should exist initially? Implement these somewhere that makes sense. Additionally, one of them can be used to refactor magic variables that are used as defaults for the feature class implementation.

Tentative list of features:

set_name
run_id
solver
objective
running time
.... ?

When declaring solver, also take care of substituting allowed types for feature (optiface/datamodel/feature.py line 45, 111 mainly).

Using python's Enum type, the basic one for now, instead of having allowed types. The example in the starter feature set is the solver Feature.


Endpoint url + fix s3 api (see #11)

With a very small modification it is possible to use alternative open-source s3-api-compatible servers, like minIO, with this plugin. This can be useful also in a non-cloud aiida installation where more workstation are available for data-storage, because minIO can scale on more than a single workstation when the space on a single workstation is finished.

Thanks @rikigigi . The fix for the open implementation makes a lot of sense. Could you please split that off to its separate PR? Then I can review that and we can merge it. For the endpoint URL: it would be great to support other S3 implementations, but I am thinking that we should implement it in a slightly different way. I should have rather made a base S3 implementation that includes this endpoint URL and then have the AWS S3 version subclass this as a special case.

Thank you @sphuber! I created a new PR, I think we can close this now and move the discussion to #14


Added C++ modules highlighting

Recently C++ modules were added to the language spec, with Visual Studio adding support of it, here's a change that adds them to the project. ;)

Thanks @alaingalvan!


RuntimeError: CUDA error: no kernel image is available for execution on the device

System:

WSL2

GPU: 3080
 python training/run_experiment.py --model_class=MLP --data_class=MNIST --max_epochs=5 --gpus=-1

Followed mentioned steps but ended up with this error
RuntimeError: CUDA error: no kernel image is available for execution on the device

Complete output
GPU available: True, used: True
TPU available: None, using: 0 TPU cores
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/torch/cuda/__init__.py:104: UserWarning:
GeForce RTX 3080 with CUDA capability sm_86 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_70 sm_75.
If you want to use the GeForce RTX 3080 GPU with PyTorch, please check the instructions at https://pytorch.org/get-started/locally/

  warnings.warn(incompatible_device_warn.format(device_name, capability, " ".join(arch_list), device_name))

  | Name          | Type     | Params
-------------------------------------------
0 | model         | MLP      | 936 K
1 | model.dropout | Dropout  | 0
2 | model.fc1     | Linear   | 803 K
3 | model.fc2     | Linear   | 131 K
4 | model.fc3     | Linear   | 1.3 K
5 | train_acc     | Accuracy | 0
6 | val_acc       | Accuracy | 0
7 | test_acc      | Accuracy | 0
-------------------------------------------
936 K     Trainable params
0         Non-trainable params
936 K     Total params
/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/utilities/distributed.py:49: UserWarning: The dataloader, val dataloader 0, does not have many workers which may be a bottleneck. Consider increasing the value of the `num_workers` argument` (try 20 which is the number of cpus on this machine) in the `DataLoader` init to improve performance.
  warnings.warn(*args, **kwargs)
Validation sanity check: 0it [00:00, ?it/s]Traceback (most recent call last):
  File "training/run_experiment.py", line 90, in <module>
    main()
  File "training/run_experiment.py", line 85, in main
    trainer.fit(lit_model, datamodule=data)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/trainer/trainer.py", line 473, in fit
    results = self.accelerator_backend.train()
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/accelerators/gpu_accelerator.py", line 66, in train
    results = self.train_or_test()
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/accelerators/accelerator.py", line 69, in train_or_test
    results = self.trainer.train()
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/trainer/trainer.py", line 495, in train
    self.run_sanity_check(self.get_model())
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/trainer/trainer.py", line 693, in run_sanity_check
    _, eval_results = self.run_evaluation(test_mode=False, max_batches=self.num_sanity_val_batches)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/trainer/trainer.py", line 609, in run_evaluation
    output = self.evaluation_loop.evaluation_step(test_mode, batch, batch_idx, dataloader_idx)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/trainer/evaluation_loop.py", line 178, in evaluation_step
    output = self.trainer.accelerator_backend.validation_step(args)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/accelerators/gpu_accelerator.py", line 84, in validation_step
    return self._step(self.trainer.model.validation_step, args)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/pytorch_lightning/accelerators/gpu_accelerator.py", line 76, in _step
    output = model_step(*args)
  File "/mnt/c/Users/user/GitHub/fsdl-text-recognizer-2021-labs/lab1/text_recognizer/lit_models/base.py", line 58, in validation_step
    logits = self(x)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/mnt/c/Users/user/GitHub/fsdl-text-recognizer-2021-labs/lab1/text_recognizer/lit_models/base.py", line 45, in forward
    return self.model(x)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/mnt/c/Users/user/GitHub/fsdl-text-recognizer-2021-labs/lab1/text_recognizer/models/mlp.py", line 37, in forward
    x = self.fc1(x)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/torch/nn/modules/linear.py", line 93, in forward
    return F.linear(input, self.weight, self.bias)
  File "/home/myuser/miniconda3/envs/fsdl-text-recognizer-2021/lib/python3.6/site-packages/torch/nn/functional.py", line 1690, in linear
    ret = torch.addmm(bias, input, weight.t())
RuntimeError: CUDA error: no kernel image is available for execution on the device

Currently getting around it with

Change cuda version in environment.yml
Remove cudnn line from  environment.yml
After setting the labs up. Run this command  conda install pytorch torchvision torchaudio cudatoolkit=11.0 -c pytorch

And lab1 passes. Not sure if it completely solves the problem though

I modified the below to make it work on my RTX3090 + Ubuntu 20:

remove both cuda and cudnn versions in environment.yml
after setting the labs up via make conda-update, run conda install -c anaconda cudatoolkit
finally run conda install pytorch torchvision torchaudio cudatoolkit=11.0 -c pytorch


[8.x] Lang Fallback

Fallback to looking for lanuage files in base_path().'/lang' if not in the typical location.

Either the code or the documentation should probably be changed - the documentation says to put the files in /lang, but the code treats /resources/lang with priority and will only use /lang as a fallback :)


fix: GetPagination methods error: "response data format is incorrect"

fix same problem #106

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Pages, queries and SourceTableTemporary

Hi I have a problems with getting SourceTableTemporary to work.
I have a page with SourceTableTemporary
If i create a page lige the following.
page 50008 "Merged Job Entries"
{
    Editable = false;
    PageType = List;
    SourceTable = "Job Journal Line";
    SourceTableTemporary = true;
....
    trigger OnOpenPage()
    begin
        FillTempTable();
    end;
....
    local procedure FillTempTable();
    var
        JobJnlLines : Query "Job Jnl Lines";
        JobLedgEntries : Query "Job Ledg Entries";
    begin
        if not IsTemporary then
            Error('Error not temp');
       ....
    end
}

But the function FillTempTable insert the record in the database instead of keeping it temporary.

Hi @superjma, I just tried your code on our latest master and I couldn't reproduce the issue as the source table is temporary as expected for me (it did not trigger then error message). Which version of the AL extension and of the server are you using?

Hi
Al-version: 0.12.15355.
Nav-server: 11.0.20348.0

Thank you for reporting the issue. It seems to be fixed in our latest builds. As you are running on NAV 2018 and this potentially requires deeper investigation, please log a support case for your problem (see FAQ - I found an issue on NAV 2018, what do I do?) if you want this to be backported.


Update versioning

@tannerbyers this is the third or fourth time this has happened; can you please be a bit more careful when making PRs?

@ljharb yes will do. When I make PR's on our repo it always defaults to airbnb. I will be more careful.


tabs_to_bottom.userchrome.css moves the titlebar to bottom

I enabled the menubar to have a window border at the top to still grab, but this also moves that. would it be possible to put the menubar back at the top?

Not possible to easily modify this script unfortunately, the menu and tab
bar are coupled together.
However you should still be able to grab the window from the address bar
(left of the Pocket icon).
On Thu, 8 Jun 2023 at 13:07, Vosjedev @.***> wrote:

I enabled the menubar to have a window border at the top to still grab,
but this also moves that. would it be possible to put the menubar back at
the top?
[image: image]
https://user-images.githubusercontent.com/100359465/244350531-543fae7c-2b29-49a4-9753-a4abeb9401c0.png
—
Reply to this email directly, view it on GitHub
https://github.com/Arty2/userstyles/issues/4, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA23GJOBAURIYZFKNTHWAXDXKGP65ANCNFSM6AAAAAAY7CG7EI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

IMO I prefer having the address bar on the bottom too! most of the time I am focusing on the main webpage and only every now and then glance down to do address/tab bar stuff. also looks like its completely broken with 119.0 now anyway...