R + Rmpfr, 80 bytes
Requires package Rmpfr.
mpfr("1.00000000238982476721842284052415179434",30 *log2(10))^(479001600/(1:12))
Gives the following, with truncations mine and some minor formatting
12 'mpfr' numbers of precision 99 bits
3.1415926535897932384...
1.7724538509055160272...
1.4645918875615232630...
1.3313353638003897127...
1.2572741156691850593...
1.2102032422537642759...
1.1776640300231973966...
1.1538350678499894305...
1.1356352767378998683...
1.1212823532318632987...
1.1096740829646979321...
1.1000923789635869829...
See below for why simpler versions don't work. Direct calculation using exponents 1/N for N=1,12 returned inaccurate value fairly early. I figured that was probably due to R or Rmpfr rounding 1/3 early, so whole number exponents would be preferred. So I calculated pi^(12!) (12!=479001600) using Mathematica, then raised it to the power of 12!/N, which would always be a whole number. I had to further tune it by passing the number to Rmpfr as a character vector (so R wouldn't round it), and by using an arbitrarily high precision in both Mathematica and Rmpfr so it would truncate accurately. Because of those arbitrary additions, I can probably shave off a few bytes, but I'm good with it as is.
R, 29 bytes
This only works if R value for pi is accurate, which it isn't. Even reassigning the variable pi to a more accurate representation does not improve accuracy, as it rounds or something around 17 decimals.
format(pi^(1/1:12),nsmall=20)
Try it online
Or, for 30 bytes
options(digits=20);pi^(1/1:12)
There's a package that gives a more accurate value for pi and other floating point numbers, Rmpfr, which you'll find referenced in questions about pi in R. One might expect the following to give the desired output.
library(Rmpfr)
Const("pi",20 *log2(10))^(1/1:12)
It doesn't. It gives
12 'mpfr' numbers of precision 66 bits
[1] 3.1415926535897932385 1.7724538509055160273 1.464591887561523232
[4] 1.3313353638003897128 1.2572741156691850754 1.2102032422537642632
[7] 1.177664030023197386 1.1538350678499894305 1.1356352767378998604
[10] 1.1212823532318633058 1.1096740829646979353 1.1000923789635869772
This is wrong on all counts by rounding or being a few off in the last digits (sidenote: the rnd.mode flag for mpfr does not fix this). Now one might think if we went up to many digits (say 100), then it would surely be correct to the first 20 digits. Nope
12 'mpfr' numbers of precision 332 bits
[1] 3.1415926535897932384...
[2] 1.7724538509055160272...
[3] 1.4645918875615232319...
[4] 1.3313353638003897127...
[5] 1.2572741156691850753...
[6] 1.2102032422537642631...
[7] 1.1776640300231973859...
[8] 1.1538350678499894305...
[9] 1.1356352767378998603...
[10] 1.1212823532318633058...
[11] 1.1096740829646979353...
[12] 1.1000923789635869771...
(Truncations mine). These don't all match OP or the other responses.
1Shouldn't
⎕PP←34
and⎕FR←1287
be part of the byte-count? – Kevin Cruijssen – 2019-11-04T14:22:07.1573@KevinCruijssen
⎕PP←34
certainly not, as it is just the print precision, not the actual precision of the returned (allowed by OP) value.⎕FR←1287
can be set as a system default (so it doesn't need to be set by the programs), making it no worse than a "compiler" flag. – Adám – 2019-11-04T15:00:42.200Ah ok, that makes sense. Thanks for clarifying. – Kevin Cruijssen – 2019-11-04T15:03:52.223